Domain-Driven Design: Tackling Complexity in the Heart of Software

by Evans Eric

Many things can put a project off course: bureaucracy, unclear objectives, and lack of resources, to name a few.

Domain-driven design is both a way of thinking and a set of priorities, aimed at accelerating software projects that have to deal with complicated domains.

It takes fastidiousness to write code that doesn’t just do the right thing but also says the right thing.

When a model doesn’t seem to be practical for implementation, we must search for a new one. When a model doesn’t faithfully express the key concepts of the domain, we must search for a new one. The modeling and design process then becomes a single iterative loop.

Manufacturing is a popular metaphor for software development. One inference from this metaphor: highly skilled engineers design; less skilled laborers assemble the products. This metaphor has messed up a lot of projects for one simple reason—software development is all design. All teams have specialized roles for members, but overseparation of responsibility for analysis, modeling, design, and programming interferes with MODEL-DRIVEN DESIGN.

(It may seem counterintuitive for a subclass to be in a layer higher than that of the parent class, but keep in mind which class reflects more knowledge of the other.)

Just using a flexible language doesn’t create a flexible system, but it may well produce an expensive one.

There is only so much partitioning a mind can stitch back together, and if the framework uses it all up, the domain developers lose their ability to chunk the model into meaningful pieces.

Don’t get hung up on UML. Sometimes the fixation on a tool, such as UML diagramming, leads people to distort the model to make it fit what can easily be drawn. For example, UML does have some features for representing constraints, but they are not always sufficient. Some other style of drawing (perhaps conventional for the other paradigm), or simple English descriptions, are better than tortuous adaptation of a drawing style intended for a certain view of objects.

An object should be distilled until nothing remains that does not relate to its meaning or support its role in interactions.

Excellent design advice from DDD.

Because cars are never assembled and driven at the same time, there is no value in combining both of these functions into the same mechanism.

VALUE OBJECTS are completely immutable.

To keep this distinction in mind, I refer to the creation of an instance from stored data as reconstitution.

Must remember this term, "reconstitution".

A table row should contain an object, perhaps along with subsidiaries in an AGGREGATE. A foreign key in the table should translate to a reference to another ENTITY object. The necessity of sometimes deviating from this simple directness should not lead to total abandonment of the principle of simple mappings.

bidirectional associations are problematic in a design.

The truth is, though, that initial models usually are naive and superficial, based on shallow knowledge.

Except the reanalysis doesn’t happen in reality, so the result is two versions of the same concept that follow different rules and even have different data. On top of that, the team members must learn not one but two ways of doing the same thing, along with all the ways they are being synchronized.

Code reuse between BOUNDED CONTEXTS is a hazard to be avoided.

Generally speaking, there is a correspondence of one team per BOUNDED CONTEXT. One team can maintain multiple BOUNDED CONTEXTS, but it is hard (though not impossible) for multiple teams to work on one together.

To be effective, the CONTEXT MAP must reflect the true practice of the teams, not the ideal organization you might decide on by following the guidelines just described.

Generally speaking, breaking up CONTEXTS is pretty easy, but merging them or changing the relationships between them is challenging.

Choose some small subdomain to start with—something duplicated in both CONTEXTS, but not part of the CORE DOMAIN.

Maybe most organizations already are doing microservices. The issue here is the choice of contexts.

But I’ll discuss a common case: An old system that is used daily in the business has been supplemented recently by a handful of more modern systems that communicate with the legacy system through an ANTICORRUPTION LAYER.

Digital decoupling

Project leaders should define BOUNDED CONTEXTS based on functional integration requirements and relationships of development teams.

There are other means of making large models tractable that should be considered before making this sacrifice. The next two chapters focus on managing complexity within a big model by applying two more broad principles: distillation and large-scale structure.

A system that is hard to understand is hard to change.

Duplication crops up when a developer does not realize that a behavior already exists elsewhere, and so the system becomes even more complex.

Domain design is interesting, technically challenging work when approached seriously, and developers can be found who see it this way.

These issues arise equally for projects that use elaborate UML models and those (such as XP projects) that keep few external documents and use the code as the primary repository of the model.

This proliferation of procedures is a symptom of a problem in the model.

Your work slows down as you try workarounds or try to negotiate with the architects.

This whole area is still undeveloped. I’ve observed a few general patterns of large-scale structures that have emerged on various projects. I’ll discuss four in this chapter. One of these may fit your needs or lead to ideas for a structure tailored to your project.

A static model can cause problems. But problems can be just as bad with a fully flexible system that allows any possible relationship to be presented.

Managers tend to move the most technically talented developers into architecture teams and infrastructure teams, because they want to leverage the skills of these advanced designers.

So Evans was already saying this decades ago.

If those people are not smart enough to design, they shouldn’t be assigned to develop software.

in practice master plans fail—because they create totalitarian order, not organic order. They are too rigid;

the existence of a master plan alienates the users [because, by definition] the members of the community can have little impact on the future shape of their community because most of the important decisions have already been made.

Better to stick to the lowest common denominator of design to do simple things.

To stop with “Everything is an object” would be like a carpenter or an architect summing up houses by saying “Everything is a room.” There would be the big room with high-voltage outlets and a sink, where you might cook. There would be the small room upstairs, where you might sleep. It would take pages to describe an ordinary house. People who build or use houses realize that rooms follow patterns, patterns with special names, such as “kitchen.” This language enables economical discussion of house design.

In every area of design—houses, cars, rowboats, or software—we build on patterns that have been found to work in the past, improvising within established themes.