What Eric Evans Would Have Changed in the DDD Book.

Here are my notes of Eric Evans talk What I've learned about DDD since the book

Essentials

Emphasize that the collaboration with the domain experts is essential. It is up to you to show the domain experts how valuable their collaboration is. If they cannot see the value of participating in the project, they will not to a good job, and they will try to avoid it.

Always produce at least three bad models. These models help to emphasize what is important.

The chapters "Distillation of the Core Domain" and "Context Mapping and Boundaries" should have been moved to the start of the big since these are the most essential areas.

Changes to Building Blocks

Domain Events

There is one new Building Block and it is the Event Object. The Event Object is an object the represents an Event that is significant to a domain expert. A benefit of domain events is that they give clearer, more expressive, models.

The events can be used for: - Representing the state (history) of entities. - Decouple systems with event streams (publish-subscribe) - Enable high-performance system.

Aggregates

Evans want to emphasize som things of aggregates. The boundaries of an aggregate need to contain transactions, distribution and concurrency.

When modelling the aggregates it is important to not over-specify on what part of the aggregate the properties and invariants are placed. Even though they are commonly placed on the aggregate root, this is not essential and it gives you a freedom if you not specify it too hard and too early.

Strategic Design

Large-Scale Structure does not come up very often and would probably have been left out of the book.

It is important to not spread modelling to thin, and to focus on the core domain and to create a clean bounded context.

Collaboration Patterns

There is two new collaboration pattern called Partners. This pattern differs from the other collaboration patterns in that it is cooperative and mutually dependent.

Another pattern is the Big Ball of Mud"_. This pattern is known as an anti-pattern since it implies that the code is just fixed as things go. This pattern is utterly pragmatic but the point Evans is making is that if there is a Big Ball of Mud in the system, it is important to define the boundaries of it, so that it doesn't spread to other systems that are more rigorously architected.

Context Mapping

• What models do we know of?
• Where does each apply? Define boundaries in words?
• Where is the information exchanged?
• The service interface may define a context boundary.

DDD and SOA

• The service interface must be defined in some context.
• Internals also, but often not the same one.
• The service interface may define a context boundary.

Precisions Designs are Fragile

Sophisticated design techniques are wasted in a ball of mud. It must be isolated with an Anti-Corruption Layer.

Not all of a large system will be well designed. Figure out what part of the system is most critical and benefits most from a really nice design.