Software Architecture

Design · Adopt

To me, software architecture is not a diagram you draw once and then forget. It is made of three things that belong together: structured documentation with arc42, a clear review method based on the iSAQB curriculum, and clean domain boundaries in microservice landscapes. Domain-Driven Design principles, like clean bounded contexts and a shared domain language, feed into that pragmatically. More on this below.

Software architect with arc42 experience: documentation as a working tool

arc42 has been my standard template for architecture documentation for more than 15 years. I have used it in projects at comSysto, codecentric, Audi and MAN. The reason is simple: arc42 gives you a fixed structure without forcing a particular technology or approach. Everyone on the team knows where to find the quality goals, where the system context is described, and where design decisions and their rationale are recorded.

ketovavaria.de, a blog run by AI agents, shows that this also works outside classic client projects. The team there keeps a complete 13-chapter arc42 documentation, and the architecture agent keeps it up to date. For me, this is good evidence that a clear documentation structure helps people and also helps agents that work together on one system.

iSAQB certification: the methodical foundation for architecture reviews

On 6 December 2013, I passed the exam for iSAQB Certified Professional for Software Architecture – Foundation Level (CPSA-F) in Munich. The curriculum covers exactly the areas that matter in an architecture review: quality requirements, design decisions, communication and documentation, and the evaluation of architectures.

In practice, I always start a review with the quality attributes. Before we talk about a solution, the team and I agree on what really matters, whether that is maintainability, performance, security or something else. Only then do I measure the solution against those goals. This keeps a review from turning into a debate about taste and makes it an assessment that others can follow.

Communication with the different stakeholders matters at least as much. Business, development and operations ask different questions about an architecture and need different answers. This is where arc42 comes back in: its structure makes it easy to have the right view ready for each audience.

Microservice domain boundaries in practice: business logic before frameworks

I have been designing microservice architectures for more than 15 years, including at comSysto, codecentric, Audi and MAN. The most important thing I have learned: a clean domain boundary matters more than any technology decision. A service with the wrong boundaries stays wrong, no matter which framework it is built with, for example Java and Spring.

That is why design starts with the business domain, not with frameworks. The key questions are: Which responsibilities belong together? Where are the natural boundaries between domains? A reliable warning sign of unclean boundaries is a business change that regularly affects several services at once. That means coupling is too high and the boundaries should be reviewed.

Domain boundaries and delivery: why canary releases are part of it

To me, domain boundaries and delivery strategy belong together. Clear domain boundaries are what allow services to be deployed independently of each other. Only then do techniques like canary releases make sense, where a new version is first rolled out to only some of the users, for example on Kubernetes/EKS. I have written about both sides in technical articles: “Microservices und die Jagd nach mehr Konversion” (Java Aktuell, 2015) and “Canary-Releases mit der Very Awesome Microservices Platform” (Java Aktuell, 2016).

Domain-Driven Design: applied pragmatically, formal method as the next step

Across 15 years of microservice architecture, I have repeatedly answered the core questions of Domain-Driven Design in practice, even without the formal vocabulary: which business responsibilities belong together, where the boundary between two domains runs, who owns the data. Those are exactly the questions bounded contexts and ubiquitous language are meant to answer — I just got there through practice rather than the book.

I know the theory well: ubiquitous language, bounded contexts and aggregates, as Eric Evans described them in 2003. What I have not yet run formally are the named workshop formats like event storming, or written-out context maps as standalone artifacts — those tools make implicit team knowledge explicit and shareable, instead of leaving it in one person’s head.

That is my concrete next step: not learning DDD as new theory, but backing the practical intuition I already have for domain boundaries with the formal methods, and making it usable across the whole team — for example by running an event storming session on the next suitable project.

How the three topics fit together

arc42 provides the structure for recording architecture decisions. The iSAQB method makes sure those decisions are measured against quality goals agreed in advance. Domain boundary practice decides how the system is split along business lines, and so whether teams and services can work and deploy independently. Domain-Driven Design rounds it off: the formal methodology for domain boundaries, which I currently draw from experience pragmatically.