We now arrived at the last post of this series about Domain-Driven Design (DDD) patterns and practices. It is about the combination of the different strategic design practices and how to start the application of them. The three strategic design…

Organizing our software into modules and contexts helps us going a long way toward clean and maintainable systems. Domain-Driven Design (DDD) describes some additional concepts or practices that go even further to organize code artifacts with standardized methods. DDD’s large…

If we start building software with domain-driven design (DDD), it can seem to be much work to model everything. Luckily, any domain of reasonable size has sub-domains of lesser importance. However, how do we separate these from the essential concepts?…

Let’s continue to look at the supple design patterns of domain-driven design (DDD). Previously we learned about Intention-Revealing Interfaces, Side-Effect-Free Functions, and Assertions. These patterns help greatly reduce mental overload and should lead to a supple design without surprises. In…

Today I would like to introduce the concept of supple design. Previously through this series about domain-driven design (DDD), we climbed up the abstraction hierarchy from class level patterns up to the context map. With supple design, we are back…

Different areas or parts of a software system are called bounded contexts in domain driven design (DDD). In the previous post of this series I tried to explain what the properties of these bounded contexts are. Now software systems very…

The next parts of this series about domain driven design (DDD) will be about bounded contexts, how to keep their integrity and integrate them with each other. In this post, I would like to introduce the bounded context pattern. When…

In the previous posts of this series about domain driven design (DDD) concepts and patterns, I introduced some of the building blocks of a domain model: Entities, Value Objects, and Factories. Today I would like to extend this list with…