Modern software architecture often struggles with excessive coupling and unclear data models. In this interview, Michael Sperber explains how functional architecture and domain-specific languages help make systems more understandable, flexible, and sustainable over time.
You criticize two central problems of modern software architecture in your session: mutable state and insufficient data modeling. Why are these two aspects so critical for software quality?
In software architecture, coupling is our worst enemy, meaning dependencies between components that make future changes more difficult. The main source of coupling in large systems is mutable state: another component modifies an object that I access. This usually happens behind the scenes and leaves no trace, yet the order of operations must still be exactly right, even in multi-threaded systems. The less of this there is, the better.
Poor data modeling is actually an unnecessary problem. We have all used software where it is obvious that all data has been forced into a rectangular table schema that does not really fit. This happens because data modeling is often shaped by our tools, such as Excel and relational databases. To break out of these tabular schemas, software architects need a certain vocabulary, namely products and sums.
Excel and databases only support products (“an address has the attributes street, postal code, and city”). The operative word here is “and”. But there are different types of addresses: it can be a street address or, for example, a postbox. A postbox naturally has completely different attributes. In rectangular schemas, the existing attributes are often misused. The street field may then contain the word “packstation”, and the post number is placed in an “additional address information” field. Eventually, everything becomes confusing and requires documentation. This can be improved by consciously modeling with products and sums.
If you want to explore this in more detail, you can read the blog article that my iSAQB colleague Stefan Wehr and I wrote when these topics were added to the iSAQB Foundation curriculum: https://funktionale-programmierung.de/2024/11/25/sums-products.html
Functional software architecture relies on controlled or no mutable state. What practical benefits does this bring in terms of maintainability and system understandability?
Simply put: everything improves. Due to reduced coupling, components in functional architectures can often be considered in isolation, without needing to understand the entire surrounding system. This makes functional architecture easier to maintain and allows it to remain flexible over time.
In addition, functional programming languages often enable more compact programs that express a concept with less code, which further improves understandability.
Another focus is on richly structured data models. What distinguishes these models from traditional approaches, and why are they so important for long-lived systems?
Traditional approaches often respond to new requirements by extending or modifying the data model. This change propagates through the database and usually across other layers of the system. Attributes increase, tables grow wider, and everything becomes more cumbersome.
In functional architecture, we rely on so-called combinator models. Instead of representing each feature individually in the data model, combinator models act as building blocks in which each component can support many different features. Good combinator models can often accommodate new requirements without any changes to the data model.
Because combinator models are created through abstraction beyond the pure domain logic, they often open up new perspectives on the domain and inspire ideas for features that would not have emerged otherwise.
You emphasize the importance of precise and well-structured domain models. At the same time, you work extensively with domain-specific languages. What role do DSLs play in bringing domain logic closer to the architecture?
Good DSLs are ultimately a continuation of good modeling. Even with combinator models, users often feel as though they have been given a new language. Sometimes, all that is needed is an additional syntax layer, and the DSL is complete.
From an architectural perspective, good DSLs separate the concise expression of domain logic from the underlying technical implementation, further reducing coupling. They also go beyond combinator models in reducing the need to extend or modify software to implement new features. In architecture, we often talk about improving maintainability, but the real goal is to make maintenance as unnecessary as possible. DSLs help achieve that.
Domain-specific languages are considered very powerful but are rarely used in practice. Why is that, and what approaches make their adoption more realistic today?
They are not as rare as one might think. In many projects, there are configuration files whose format has grown out of control because no one really took care with their design. These are effectively DSLs, just poorly designed ones.
Building good DSLs requires not only care and good taste but also some basic knowledge of compiler construction, which many developers and architects do not have or may have forgotten. However, this knowledge can be picked up relatively quickly, for example in an iSAQB DSL training.
What advantages do DSLs offer compared to traditional user interfaces or AI-based interfaces, and in which scenarios do they show their greatest potential?
DSLs are used where traditional user interfaces reach their limits because they are simply not expressive enough. AI-based interfaces can sometimes achieve similar results when addressed in domain language and allowed to act accordingly.
Whether this makes sense depends on the requirements. DSLs provide precision, determinism, and traceability. They also consume orders of magnitude fewer resources and can run locally. If these aspects are not important to you, you can reach for AI.
More on this topic at the Software Architecture Forum 2026. In one session, Michael Sperber will show how functional architecture helps reduce coupling and improve data modeling. In another session, he will demonstrate how domain-specific languages bring domain logic closer to the architecture and enable more flexible systems.
