Domain Driven Design (DDD)

What is Domain-Driven Design (DDD)?

Domain-Driven Design (DDD) is a strategic approach to software development that focuses on placing the functional domain of a system at the center of the architecture. Instead of focusing primarily on technical aspects such as databases, frameworks or infrastructure, DDD relies on close interaction between developers and domain experts. The aim is to develop a common understanding of the specialist logic and to map this directly in the code.

DDD consists of strategic and tactical principles that help to model complex business logic in a clear, maintainable and scalable way. This is done by:

• Ubiquitous Language: A standardized, domain-specific language for developers and specialist departments.
• Bounded contexts: Clear delineation of responsibilities within the software.
• Domain models: Direct mapping of business logic in code using entities, value objects, aggregates and domain services.
• Event-driven architecture: Use of domain events for communication between components.

Why is domain-driven design important?

Software projects with complex business logic often fail because:

• developers do not fully understand the technical logic.
• domain knowledge is not consistently anchored in the code.
• Software architecture is too strongly characterized by technical rather than functional aspects.
• Lack of communication between developers and technical experts leads to misunderstandings.

DDD helps to solve these problems by creating a clear structure and requiring close collaboration between developers and business teams. The advantages:

1. Better comprehensibility and maintainability
   • By focusing on technical concepts, code can be read and understood more intuitively.
   • Changes in the domain can be mapped more easily in the code.
2. More efficient collaboration
   • A standardized ubiquitous language facilitates communication between all parties involved.
   • Misunderstandings between developers and business stakeholders are reduced.
3. Scalable and sustainable software
   • The clear separation of bounded contexts makes it easier to modularize systems.
   • Scaling is made easier, especially in microservice architectures.
4. Better adaptability to changing requirements
   • Companies and markets are constantly changing – DDD provides a flexible architecture that absorbs changes more easily.

Differentiation from other architectural approaches

DDD is not a concrete architecture model, but a philosophical approach to software design. Nevertheless, there are frequent overlaps and misunderstandings with other architectural patterns:

1. DDD vs. layered architecture
   • Layered architecture (e.g. 3-tier or hexagonal architecture) separates technical aspects such as presentation, business logic and data storage.
   • DDD focuses on the domain, while layered architecture is usually focused on technological aspects.
   • Both can be combined: DDD can be implemented in a layered architecture (e.g. with a dedicated “domain layer”).
2. DDD vs. microservices
   • DDD can support microservices by using bounded contexts to define clear interfaces between microservices.
   • But DDD is not synonymous with microservices! It is also suitable for monolithic architectures.
   • Microservices without DDD often lead to “distributed chaos” because they do not have a clearly defined functional boundary (bounded context).
3. DDD vs. REST API design
   • Many REST APIs are technically driven and based on CRUD models.
   • DDD APIs model business logic, not just data storage. For example, commands and domain events are often more useful than simple CRUD operations.

Target group: When and for whom is domain-driven design useful?

DDD is not the right choice for every project. It shows its strengths particularly in complex software projects with sophisticated business logic. Here are some guidelines on when DDD makes sense:

✅ DDD is particularly suitable for:

• Companies with a dynamic, frequently changing business logic (e.g. banks, insurance companies, e-commerce).
• Teams that require close collaboration with domain experts.
• Software that is maintained and expanded over the long term.
• Microservices and scalable systems that require a clear separation of responsibilities.

❌ DDD is less useful for:

• Small or one-off projects where the business logic is very simple.
• CRUD applications that only map simple data operations.
• Rapid prototyping when a solution needs to be developed quickly.
• Short-lived applications that do not require long-term maintenance.

Domain-Driven Design – compact and to the point

• DDD helps to model complex business logic in a clear, comprehensible and scalable way.
• Focus on the domain instead of technical details.
• Supports team communication through a common language (ubiquitous language).
• Can be combined with layered architecture, microservices and event-driven design.
• Not useful for every project, but especially for complex software systems that have grown over the long term.

History and origin of Domain-Driven Design (DDD)

Emergence of domain-driven design by Eric Evans

Domain-Driven Design was developed by Eric Evans who published his book “Domain-Driven Design: Tackling Complexity in the Heart of Software“ in 2003. This work set a milestone in software development by introducing a new approach to tackling complex business logic. Evans recognized that many software projects fail because developers do not understand the actual business domain deeply enough. His solution was to put the domain at the center of the software architecture and establish a common language between developers and business stakeholders.

DDD differs from other methods in that it offers not only technological, but also conceptual principles for modeling software. It is less about a specific technical framework and more about a strategic approach to software architecture.

Influence on modern software architectures

Since its publication, DDD has significantly changed the way software is designed, especially in enterprise applications. While traditional software architectures were often oriented towards technical layers (e.g. database, application, UI), DDD focused on the functional structure of the domain. This resulted in new best practices for modularization, loose coupling and testability.

Further development and influence on modern frameworks

DDD has influenced numerous modern architectural principles and frameworks. These include, among others:

• Spring (Java environment):
  • Frameworks such as Spring Boot and Spring Data offer native support for many DDD concepts, especially for repositories and aggregate roots.
• NET (C# environment):
  • The ASP.NET Core Framework supports DDD with Dependency Injection, CQRS and Event Sourcing.
• Event Sourcing & CQRS:
  • DDD has contributed significantly to the popularity of event sourcing and CQRS (Command Query Responsibility Segregation) as architectural approaches.
  • Systems such as Axon Framework (Java) or EventStore (C#) were strongly inspired by DDD.

Thanks to these further developments, DDD is now a fundamental concept in modern software development, especially for cloud-native applications, microservices and complex enterprise software.

Basic concepts and principles of domain-driven design

DDD is based on a series of core principles and architectural patterns that enable a clear separation of technical and functional aspects.

Ubiquitous Language

Problem:
In many software projects, there is a discrepancy between the language of the developers and the language of the technical experts.

Solution:

• Introduction of a common language that is understood by developers and domain experts alike.
• This language is adopted directly in the code – classes, methods and variables reflect technical concepts.

Example:
In a banking application, there could be a class Girokonto with methods such as BuchungVornehmen() instead of processTransaction().

Bounded Contexts

Problem:
In large systems, there are often confusing domain models that lead to misunderstandings and unclear responsibilities.

Solution:

• Division of the system into clearly defined sub-areas (bounded contexts).
• Each bounded context has its own ubiquitous language and clear interfaces to other contexts.

Example:
An e-commerce system could have separate bounded contexts for orders, payment processing and customer management.

Entities vs. value objects

Entities:

• Have a unique identity that makes them unmistakable throughout their life cycle.
• Example: A Kunde with a unique Kunden-ID.

Value Objects:

• Are interchangeable values without identity.
• Example: A Adresse consists of a street, zip code and town – but two identical addresses cannot be distinguished.

When should you use entities or value objects?

• Entities are suitable for changeable data that requires an identity.
• Value Objects are suitable for unchangeable data that can be exchanged or copied.

Aggregates (grouping of domain objects)

Problem:
If a system has many linked objects, the management of dependencies can quickly become complex.

Solution:

• Grouping of related entities and value objects in an aggregate.
• The aggregate has a central root (aggregate root) that serves as a single access point.

Example:
A Bestellung aggregate could contain the following entities and value objects:

• Order (Aggregate Root)
• Order items (entities)
• Delivery address (Value Object)

Advantage: External components only interact with the Aggregate Root, which prevents inconsistencies.

Repositories (data access in DDD)

Problem:
Direct access to databases can lead to business logic and persistence being mixed up.

Solution:

• Repositories encapsulate data access and offer a domain-specific API for aggregates.
• This keeps the domain logic separate from technical details (SQL, ORM).

Example:
A BestellRepository could offer methods such as findeBestellungNachKunde(Kunde k) instead of streaming an SQL query.

Domain events (event-based communication in DDD)

Problem:
If an important state changes in a domain, several components often have to react to it.

Solution:

• Introduction of domain events that signal changes in the system.
• Events can be subscribed to by other parts of the system.

Example:

• BestellungErstelltEvent is triggered when a new order is received.
• VersandService reacts to this and starts the shipping process.

DDD and event sourcing often complement each other perfectly, as both rely on event-based systems.

Factories & Services

In DDD, business logic is not written in entities if it cannot be clearly assigned to an individual object. There is a solution for this:

• Factories:
  • Responsible for the creation of complex aggregates.
  • Example: BestellungFactory creates an order with all the required items and values.
• Services:
  • Contain functional logic that is not directly assigned to an entity.
  • Example: RabattService calculates discounts for orders.

Interim conclusion

• DDD is a powerful approach for modeling complex business logic.
• It brings clear structures, separation of responsibilities and close cooperation with business experts.
• Concepts such as ubiquitous language, bounded contexts, aggregates and domain events create robust and scalable software.
• Modern frameworks such as Spring, .NET and event sourcing technologies already integrate many DDD principles natively.

➡️ If software is more than just CRUD operations, then DDD is a decisive factor for long-term success.

Strategic design (high-level architecture)

Strategic design in Domain-Driven Design (DDD) focuses on the structured division of complex systems into clear domain areas. The focus here is on demarcation, interoperability and scalability.

Bounded contexts and context mapping (context maps)

• A bounded context defines the boundaries of a domain model and ensures that terms and business logic remain consistent.
• In complex systems, there are often several bounded contexts that encapsulate different parts of a system.
• Context mapping helps to visualize and analyse the relationships between these contexts.

Taktisches Design (Detailkonzepte)

Tactical design concerns the concrete modeling of business logic, data structures and architecture patterns.

• Entities and value objects (identity vs. value equality)
• Entities are uniquely identifiable objects with a lifespan and individual changes. Example: customer, order, product.
• Value objects represent exchangeable, unchangeable values such as currencies, addresses or coordinates.

Aggregates & Aggregate Roots (Encapsulation and transaction limits)

• Aggregates are groups of objects that are managed as a single unit.
• An aggregate root is the entry point through which all changes to the aggregate are made.
• Aggregates help to ensure data consistency and avoid uncontrolled dependencies.

Domain services (business logic outside of objects)

• If a business logic does not clearly belong to an entity or a value object, it can be encapsulated in a domain service.
• Example: Calculation of delivery costs based on several factors.

Application Services vs. Domain Services (Separation of application logic)

• Application services control application processes and orchestrate domain logic without containing direct business logic.
• Domain services contain pure business logic and are independent of infrastructure or external dependencies.n.

Factories & Repositories (Creation and persistence of domain objects)

• Factories encapsulate complex object instantiations when direct constructor calls are not sufficient.
• Repositories abstract access to data sources in order to consistently store and retrieve an aggregate.

Context Mapping: Typical patterns for relationships between bounded contexts

Context mapping is a technique in Domain-Driven Design (DDD) that describes how different bounded contexts interact with each other within a system and which patterns can be used for their collaboration.

📚 Quelle: Eric Evans (2003) – “Domain-Driven Design: Tackling Complexity in the Heart of Software“

• Shared Kernel: Two teams or systems share a common code base for critical domain logic.
• Customer-Supplier: One system (customer) is dependent on another (supplier), which requires clear interfaces.
• Conformist: A dependent bounded context adopts the terminology and model of another without making any adjustments.

📚 Zusätzliche Quelle: Vaughn Vernon (2013) – “Implementing Domain-Driven Design“, Chapter about Context Mapping Patterns.

Anticorruption Layer (ACL)

An anti-corruption layer (ACL) is a protective layer that prevents external systems or incompatible models from directly influencing the domain logic by enabling translation and decoupling between systems.

📚 Quelle: Eric Evans (2003), Kapitel 14 – “Maintaining Model Integrity”

• Objective: To protect the internal domain logic by introducing a translation layer between incompatible systems.
• Example: If a new system has to communicate with an old, unstructured legacy system, the ACL prevents a direct link.

📚 Additional source: Newman, Sam. Building Microservices: Designing Fine-Grained Systems. 2nd ed. O’Reilly Media, 2021

Shared Kernel & Separated Ways

Shared Kernel and Separated Ways are two opposing strategies for splitting systems: While a shared kernel uses a common code base for critical domain logic, separated ways pursue a complete separation without dependencies between the systems.

📚 Source: Eric Evans (2003), Chapter 14 – “Strategic Design”

• Shared Kernel: Teams or subsystems share a central code base to avoid redundant implementations.
• Separated Ways: If two systems are completely separate because they have no functional dependencies, each remains self-sufficient.

Open Host Service & Published Language

An Open Host Service provides a central, well-defined interface through which multiple external systems can access a domain, while Published Language defines a standardized communication protocol to avoid misunderstandings between systems.

📚 Source: Vaughn Vernon (2013), Chapter about Open Host Service Patterns

• Open Host Service: A clearly defined interface (API) via which several clients can interact with a system.
• Published Language: A standardized, well-defined protocol (e.g. REST, GraphQL or gRPC) that serves as a communication standard between bounded contexts.

Event Storming as a modeling method

Event Storming is an interactive workshop technique for modelling business processes in domain-driven software development, in which central events are identified and visualized in a sequential representation to create a common understanding between developers and business experts.

📚 Source: Brandolini, Alberto. Introducing Event Storming. 1st ed. Leanpub, 2013.

• Event Storming is a workshop technique for visually modeling business processes using events.
• Core idea: Domain experts and developers work together to visualize critical processes and event flows.

📚 Additional source: “Event Storming: A practical guide to business process discovery”, Alberto Brandolini.

DDD patterns are an integral part of modern software architecture and have a major influence on microservices, event sourcing and CQRS, among other things.

DDD in practice

DDD is present in many modern architectures and has a direct influence on microservices, event sourcing and CQRS.

Use in microservices (DDD as an architectural basis)

Microservices often correspond to independent bounded contexts that cover a specific domain.
DDD helps to define clear interfaces and reduce dependencies between services.

Event Sourcing & CQRS (Command Query Responsibility Segregation)

Event sourcing saves every change as an event instead of overwriting the current status of an object.
CQRS separates read and write models to improve scalability and performance.

Exemplary implementations in various programming languages

Java with Spring Boot: use of hexagonal architecture, JPA and domain events.
.NET with Entity Framework: Use of aggregates, repositories and domain services.
Python with FastAPI or Django: implementation of aggregates and event-driven architecture.
Best practices and common mistakes

✅ Best practices:

• Define clear bounded contexts to avoid unnecessary dependencies.
• Use event storming to model business logic with domain experts.
• Keep domain logic independent of databases and infrastructure.

🚨 Common mistakes:

• Overengineering: DDD is not suitable for every small project.
• Lack of communication between developers and specialist departments.
• Poor interfaces between bounded contexts lead to unnecessary coupling.

Challenges and limitations of DDD

Despite its advantages, DDD is not always the best choice for every software solution.

When is DDD overkill?

• For small, CRUD-centric applications without complex business logic, DDD can add unnecessary complexity.
• If a team does not have close collaboration with domain experts, the ubiquitous language can be difficult to implement.
• Modeling and ubiquitous language effort
• The introduction of DDD requires detailed modeling of the domain.
  Without clear communication, DDD models may not correctly reflect reality.

Challenges when introducing in teams

• Developers have to deal intensively with domain modeling and architecture principles.
• There may be resistance to the additional abstraction effort if teams are used to procedural approaches.
• Integration with existing systems (legacy software)
• Monolithic legacy systems often do not have a clear separation of business logic and infrastructure.
• The introduction of DDD into existing systems requires a step-by-step migration or a clear interface strategy (e.g. anti-corruption layer).

Conclusion

Domain-Driven Design is a powerful architectural paradigm that facilitates the development of complex software through clear domain models. It helps to bridge the gap between developers and specialist departments and promotes a sustainable architecture.

However, DDD is not suitable for every project – small applications in particular often do not benefit from the additional complexity. However, those who use DDD correctly create scalable, comprehensible and future-proof software architectures. 🚀

Rock the Prototype Podcast

The Rock the Prototype Podcast and the Rock the Prototype YouTube channel are the perfect place to go if you want to delve deeper into the world of web development, prototyping and technology.

🎧 Listen on Spotify: 👉 Spotify Podcast: https://bit.ly/41pm8rL

🍎 Enjoy on Apple Podcasts: 👉 https://bit.ly/4aiQf8t

In the podcast, you can expect exciting discussions and valuable insights into current trends, tools and best practices – ideal for staying on the ball and gaining fresh perspectives for your own projects. On the YouTube channel, you’ll find practical tutorials and step-by-step instructions that clearly explain technical concepts and help you get straight into implementation.

Rock the Prototype YouTube Channel

🚀 Rock the Prototype is 👉 Your format for exciting topics such as software development, prototyping, software architecture, cloud, DevOps & much more.

📺 👋 Rock the Prototype YouTube Channel 👈  👀 

✅ Software development & prototyping

✅ Learning to program

✅ Understanding software architecture

✅ Agile teamwork

✅ Test prototypes together

THINK PROTOTYPING – PROTOTYPE DESIGN – PROGRAM & GET STARTED – JOIN IN NOW!

Why is it worth checking back regularly?

Both formats complement each other perfectly: in the podcast, you can learn new things in a relaxed way and get inspiring food for thought, while on YouTube you can see what you have learned directly in action and receive valuable tips for practical application.

Whether you’re just starting out in software development or are passionate about prototyping, UX design or IT security. We offer you new technology trends that are really relevant – and with the Rock the Prototype format, you’ll always find relevant content to expand your knowledge and take your skills to the next level!