I’m a software engineer based in Heraklion, working at Epignosis, where I focus on building systems that are intentional, testable, and designed with clear boundaries.
Most of my technical energy goes into Domain-Driven Design and Test-Driven Development, helping teams make decisions explicit instead of accidental. I care about architecture as a practice. That means refining constraints, clarifying trade-offs, and strengthening our CI process when needed so that quality is enforced, not assumed.
I’m particularly interested in socio-technical systems and how team structure, communication, and incentives shape the architecture we end up with. Architectural Katas matter to me because they create a safe environment to practice judgment, defend decisions, and learn from alternative approaches before the stakes are production-level.
I’m a software engineer based in Heraklion, working at Epignosis, where I focus on building systems that are intentional, testable, and designed with clear boundaries.
Most of my technical energy goes into Domain-Driven Design and Test-Driven Development, helping teams make decisions explicit instead of accidental. I care about architecture as a practice. That means refining constraints, clarifying trade-offs, and strengthening our CI process when needed so that quality is enforced, not assumed.
I’m particularly interested in socio-technical systems and how team structure, communication, and incentives shape the architecture we end up with. Architectural Katas matter to me because they create a safe environment to practice judgment, defend decisions, and learn from alternative approaches before the stakes are production-level.
Architectural Katas were created by Ted Neward to solve a problem: architects rarely practice their craft. Most people design systems only a handful of times in their careers, so they never develop the judgment that comes from repetition.
The kata format creates those practice opportunities. Teams work on realistic architectural problems, make design decisions, and defend those decisions when challenged. The learning happens when you see other teams solve the same problem differently and understand the assumptions behind each approach.
We run these sessions at Epignosis because our engineers need that practice too. It’s one of the few ways to develop architectural judgment outside of production systems.
This workshop is for anyone who wants that practice. You might be a developer learning to think architecturally, a tech lead seeking feedback on your decisions, or an architect wanting more repetitions. The format works because it forces clear articulation and exposes you to alternatives.
A discussion of building global success and how artificial intelligence is transforming the world.
