![\"\"](\"https:\/\/test.itsonix.eu\/wp-content\/uploads\/2026\/05\/02_Strategic.jpg\")
<\/p>\n\n\n\nThe changes our world has undergone in recent years are leading to increasing complexity in all areas. This also raises the demands placed on the software we use. How can the growing complexity of real-world processes be mapped into functional software systems in a way that promotes productivity? The Domain-Driven Design approach has proven itself for us\u2014IT Sonix\u2014in large and complex software projects. But what exactly is Domain-Driven Design? The term was established in 2003 by Eric Evans in his book *Domain-Driven Design: Tackling Complexity in the Heart of Software*. Essentially, it is a collection of tools and techniques designed to help model complex software. In addition, mindsets and principles for increasing productivity are a central component of Domain-Driven Design. This increase in productivity is achieved through a particularly detailed focus on the subject matter and reality of the business logic being modeled.
Developers and subject matter experts work closely together during the modeling process, thereby creating a conceptual framework that extends all the way into the code. What\u2019s interesting about this approach is that the model initially relies solely on language, and nothing needs to be programmed at first. In both theory and practice, Domain-Driven Design can be divided into two major areas: Strategic Design and Tactical Design.
While strategic design focuses on architecture\u2014that is, defining the context and the relationships within it\u2014tactical design deals with the implementation of the model that has been developed. However, before we delve deeper into modeling and code in the following sections, let\u2019s briefly explain the key terms of strategic design.
<\/p>\n\n\n\n
<\/p>\n\n\n\n
Strategic Design provides valuable concepts for the proper representation of real-world business processes in software: domain model, ubiquitous language, and bounded context.
As the name suggests, the domain model deals with domains. Here, domains refer to reality\u2014for example, the entire company or the business domain\u2014rather than the end product, the software. These domains can in turn be subdivided into subdomains, such as departments, teams, or business processes. Of course, the domain model is not reality itself, but rather an abstraction of it. Language remains the most suitable means of translating reality into a model, which is why it receives particular attention in Domain-Driven Design.
The key to success here lies in the ubiquitous language. \u201cUbiquitous\u201d means \u201cpresent everywhere,\u201d and that is precisely what distinguishes domain-driven design: Subject matter experts and developers work together to develop a language that is spoken by everyone involved and that remains consistent from the domain all the way into the code. The Ubiquitous Language is bounded by the Bounded Context.
In Domain-Driven Design, a model derives its meaning from the context in which it is applied, and the bounded context defines the scope of a model for a specific purpose. This distinction is particularly important when a specific concept within a domain is represented by different models. For example, the term \u201ecustomer\u201d has a different meaning for support than it does for the sales department. Although it refers to the same customer within the domain, different bounded contexts can be defined here, each of which models a customer that is appropriate for the subtasks of that context.
Defining bounded contexts for a specific domain is one of the greatest challenges in Domain-Driven Design. Collaborative methods such as Event Storming or Domain Storytelling are well-suited for this purpose, as they allow domain experts and development teams to explore the domain together. The resulting visualizations provide an initial basis for identifying the most independent parts of the domain and defining them as bounded contexts.
The identified bounded contexts are already essential for team organization, since each context is always managed by a single team. A team can manage multiple contexts, but never the other way around\u2014multiple teams cannot manage a single context. Context mapping can also be used to describe dependencies between contexts and, consequently, the types of communication between teams.
<\/p>\n\n\n\n
![\"\"](\"https:\/\/test.itsonix.eu\/wp-content\/uploads\/2026\/05\/03_Tactical.jpg\")
<\/p>\n\n\n\n
Once the domain model, a ubiquitous language, and the bounded context have been defined, work can begin on designing and implementing specific software structures and patterns. This is the task of tactical design\u2014with its designated building blocks: value object, entity, aggregate, repository, service, and factory. These are sufficient to model any domain.
A value object is the smallest building block of a domain and is defined solely by its properties\u2014it has no identity, its properties are immutable, and it encapsulates a primitive value. Consequently, value objects that share the same properties can be interchanged. For example, in Domain-Driven Design, a separate object is generated for each ZIP code\u2014an approach that can also be applied to other complex data types, such as monetary amounts. Any arithmetic operation involving a value object defined as a monetary amount would create a new value object from the resulting value. No matter how small the real-world counterpart may be, in Domain-Driven Design there is a model for everything.
One of the advantages of this method is that an object can be created for everything, and it is not just a variable name, which means it cannot be confused with others (strings). The value of the object is immutable. A value object can also consist of multiple value objects, such as an address, which is then composed of the different value objects \u201cstreet,\u201d \u201czip code,\u201d and \u201ccountry.\u201d.
Entities are the next key building block in modeling. Unlike value objects, entities have a unique identity. They are also not dependent on the properties assigned to them\u2014these properties are variable and interchangeable and have no impact on the entity\u2019s identity. It is the entities that form the core of the entire Domain-Driven Design and, ultimately, of the software itself.
If we stick with our example of streets and ZIP codes, an individual could be considered an entity. The individual remains the same person even if their address changes, and their identity distinguishes them from another individual with the same name. However, entities can also represent business functions. If subject matter experts determine that a business process requires something to fulfill a specific knowledge function, a separate entity is usually created for that purpose.
In Domain-Driven Design, value objects and entities are organized hierarchically. This requires aggregates. Instead of splitting related logic in the code into different services\u2014which can lead to inconsistencies if calls are made incorrectly\u2014aggregates encapsulate all business logic related to a specific concept (bounded context); they define invariants. As a result, only interfaces that always produce a consistent state are exposed externally.
For business functions that are intended to modify multiple entities, the aggregate is always used. In this case, changes are made to the aggregate root\u2014which encompasses all entities within the aggregate\u2014rather than to the individual entities themselves. This is the only way to ensure that these functions are actually performed on all entities where necessary. Operations on aggregate roots correspond to transaction-like approaches used in databases.
Repositories are needed to represent a set of aggregate roots. Within the domain, they are completely independent of persistence technology and are usually just an abstraction of it. They are implemented only through the infrastructure layer.
For technical details that cannot be represented by an entity or value object, there is the option to define them as a service. Although this is a rare occurrence\u2014since the building blocks mentioned above can be used to define nearly everything\u2014services can still be helpful for modeling certain functionalities that, for example, do not operate hierarchically or do not exist as entities at all.
The Factory allows you to delegate the responsibility for creating complex aggregates to a separate object.
<\/p>\n\n\n\n
![\"\"](\"https:\/\/test.itsonix.eu\/wp-content\/uploads\/2026\/05\/04_Architecture.jpg\")
<\/p>\n\n\n\n
In addition to these purely domain-specific building blocks, it is also necessary to implement technical aspects. These should be organized in such a way that there is a clear separation of purpose and loose coupling among them. Domain-Driven Design provides a layered architecture model for this purpose. This model consists of: Infrastructure, Interfaces, Application, and Domain.
The Infrastructure layer supports all other layers and often consists of implementations of domain abstractions. Examples include database repositories, message backends, REST clients, and external libraries.
The next layer consists of interfaces that represent the external interfaces, such as REST endpoints or message handlers. They form the topmost layer and are therefore allowed to access all underlying layers. The key principle of domain-driven design is that the domain does not develop any dependencies on the infrastructure. The rule here is that access must only occur from the top down, and not the other way around. However, exceptions are possible. For example, the interface layer may access the domain directly without going through the application layer. This often happens when data simply needs to be read, such as via a REST interface. The interface layer handles serialization and validation. Primitive data, such as a simple ID, is converted here into a value object, which also serves to validate the input parameters. Use cases and domain logic do not fall within its scope.
The application layer is responsible for use cases. This is where complete use cases are defined and coordinated, though without domain logic. Database transactions and security mechanisms\u2014such as user permissions\u2014typically take place at this level. When it comes to user permissions in particular, difficulties can sometimes arise regarding the assignment of the correct layer. To what extent are these part of the domain, or are they merely technical tools? If they are purely technical in nature, then the Application Layer is designated for them in Domain-Driven Design. It is important to note that this layer is independent of the calling interface\u2014that is, the layer above it. The Application Layer should use only objects from the domain for input and output, since it merely uses them and does not transform them. It is recommended that each method in this layer interact with no more than one aggregate root to keep complexity low. If a use case requires interaction with multiple entities, this may indicate the need for an additional aggregate root that encapsulates them and ensures their consistency and invariants.
The final layer\u2014the heart of the software\u2014is the domain itself. It contains all domain logic\u2014even if only as an abstraction\u2014and is consistently guided by the ubiquitous language defined in the strategic design.
Since the domain model has no dependencies on any of the other layers, Domain-Driven Design can also be implemented using a hexagon or onion layer model. Access is always from the outside in, and each layer has its own authorization.
<\/p>\n\n\n\n
When implementing complex and large-scale projects, the Layered Architecture Model is particularly valuable to us. The clearly separated layers help us conceptualize the business logic completely independently of the technologies used. For example, if something changes in the business rules, it only needs to be adjusted in the domain layer without significantly affecting the other layers. In addition, Domain-Driven Design makes it possible to easily discern the business logic from the code in the domain layer, since it doesn\u2019t rely on technologies such as databases, REST interfaces, etc. At the same time, new technologies can be implemented without compromising the business logic.
Since implementing Domain-Driven Design involves a great deal of effort, this approach is recommended primarily for very large and particularly complex projects. However, this method excels in nearly every respect, as the isolated domain layer and the ubiquitous language\u2014used consistently across all layers, right down to the code\u2014ensure that all business logic can be traced back to the domain.<\/p>","protected":false},"excerpt":{"rendered":"
Die Ver\u00e4nderungen, die unsere Welt in den letzten Jahren durchlaufen hat, f\u00fchren zu einer zunehmenden Komplexit\u00e4t in allen Bereichen. Damit steigen auch die Anforderungen an die Software, die wir nutzen. Wie kann der steigende Grad an komplexen Abl\u00e4ufen unserer Wirklichkeit in funktionsf\u00e4higen Softwaresystemen produktionsf\u00f6rdernd abgebildet werden? Der Ansatz des Domain-Driven Design hat sich f\u00fcr uns […]<\/p>\n","protected":false},"author":4,"featured_media":932,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[5],"tags":[],"class_list":["post-927","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-softwareentwicklung"],"acf":[],"yoast_head":"\n