DDD.17 – Bringing the strategy together

Strategic design is composed by 3 complementary principles:

  1. Context (Context map, bounded context)
  2. Distillation (Core Domain)
  3. Large scale structure (Evolving order)

Continue reading “DDD.17 – Bringing the strategy together”


DDD.16 – Large-scale structure

Segregating the domain into bounded contexts its a good start into maintainability, however if in every bounded context we have a different structure it can and will become cumbersome to understand the current bounded contexts and to further develop new bounded contexts.

For this reason, the team should rely on a simple generic structure to follow in every bounded context. This way, every developer in the team will be familiar with the global structure of every bounded context, making communication and collaboration easier between developers and teams.

Nevertheless, this does not mean the structure must be frozen. It can, and should, evolve as needed. Continue reading “DDD.16 – Large-scale structure”

DDD.15 – Distillation

Distillation is the process of identifying the domain, decoupling it, isolating it, clarifying it and making it explicit, allowing us to focus on what is more relevant and having it maintainable.

There are a few techniques that can be used to distil a model.

Each of these techniques requires a successively greater commitment, but a knife gets sharper as its blade is ground finer. Successive distillation of a domain model produces an asset that gives the project speed, agility, and precision of execution.

e-book loc. 6509

Going through this distillation process has several benefits:

  • Makes the overall design explicit and known;
  • Distinguishes what is Core Domain from what is Generic Domain, reducing them to manageable sizes;
  • Focus the software evolution (development and refactoring) in what is more relevant at a given moment.

Continue reading “DDD.15 – Distillation”

DDD.14 – Maintaining model integrity

When working in a large system, with a large model where we have several teams working on it, a section of the model will likely end up being interpreted, and adjusted in code, in different ways by the different teams.

These different interpretations and code adjustments will end up corrupting the model, leading to incoherent code and eventually bugs.

The best way to deal with this issue is to break the large model into smaller independent models. Breaking down a model is done by identifying bounded contexts and using context maps to identify their borders and relationships between them.

Continue reading “DDD.14 – Maintaining model integrity”


As an application grows, the code quantity and complexity both grow with it. The quantity of developers and teams of developers also grow and system wide decisions have more impact and must be negotiated and decided by many people. These system wide decisions are very difficult to make because there are many points of view: design and politics intersect.

Continue reading “DDD.IV – STRATEGIC DESIGN”

DDD.12 – Relating Design Patterns to the Model

Design Patterns are very technical patterns in code, while Domain Patters are conceptual patters in the model.


Some times, we have different ways in which we can perform an action, a process. In order to decide which strategy we are going to use at run time, we will eventually have a conditional.

In a naive approach we would have a method with as many conditionals as strategies to to perform the action, and all strategies coded directly in that same method. An approach which is a bit better, is to have a method for each different strategy, but still in the same class.

Using the STRATEGY design pattern, we create a class per each strategy algorithm. All of those strategy classes will implement a common interface so that the calling code can use either strategy class without caring which one it is actually executing. This will completely decouple the calling code from the concrete implementation of the different strategies.

The calling code will then use an ABSTRACT FACTORY to instantiate the appropriate strategy class according to a SPECIFICATION.


The composite pattern tries to simplify the usage of a complex structure of an object, by modelling that structure in as a tree where all elements are of the same type.

An example can be the products categories of a webshop. In this case, we have the categories completely decoupled from the products. It doesn’t really matter what products the category has inside. A category can have several categories inside, and those can have other categories in them, and so forth, so on, building the mentioning tree like structure where all elements have the same interface.

The example given by Eric Evans, is about travel routes, where each route is composed by an origin, a destination, and several smaller routes which are composed by even smaller routes and so on.

This post is part of a set of posts with my personal notes about all the chapters in the book “Domain Driven Design” by Eric Evans. I will do this as I read through the book, and take notes on the concepts I personally find more relevant.