Eric Evans – What I’ve learned about DDD since the book

At the QCon London 2009 conference today, Eric Evans presented recent advancements in Domain Driven Design in the talk titled What I’ve learned about DDD since the book. Evans started the presentation by saying that it has been five years since the DDD book was published, and projects which he has worked on meanwhile and teams he helped have given him new insights and ideas since then. Here are the the things he pointed out:

• Creative collaboration of domain experts and software experts is essential. When most projects get their hands on the domain expert they don't utilise their time properly. Starting with a requirements document and going through the boring list of requirements will drive domain experts away and they will become “too busy” to help. Like anyone else, domain experts don't like to do things that they don't see value in. We need to use their time efficiently and really show how valuable their participation is. Instead of going through an itemised list of boring requirements, Evans suggests using their time to explore the domain, prototype, make it a creative process and ensure that the value is evident.
• Exploration and experimentation is essential. Teams usually stop when they get a first useful model that does the job. Evans said that with this, “you are leaving so many opportunities on the table”. Exploring models is cheap if you're brainstorming at the whiteboard or prototyping, and “If you get nothing but good ideas in a modelling session, you're not being very creative “. Evans suggested rule not to stop modelling until we have produced three bad models.
• Shaping and reshaping the ubiquitous language with emerging models shaping is essential.
• Expressing context boundaries is essential. This is covered in chapter 14 in the book and Evans said that this is one of the few regrets he has about the way he wrote the book and that he would do it differently if he had to do it again. Putting effort into defining contexts and boundaries is essential to get to good models. Evans said that “the reality is that there is always more than one model” and mapping these models out is crucial to setting the stage for success of a DDD project.
• Teams should be focusing more on the core domain. Similar to the previous point, core domains are covered in chapter 15, very late in the book, and deserve much more emphasis in the whole process. Lots of teams get it wrong by trying to model every single thing in detail. Evans suggests intensively model things that are really worth modelling but not wasting time on modelling the whole thing very precise, as the benefits quickly diminish. He suggested focus more on the core domain and modelling that properly. Evans said: “If you're not working on the core domain, figure out what the core domain is and work on that”. That is why clean and bounded contexts for the core domain are important.
• Evans said that the Big ball of mud is arguably the dominant and the most successful software architecture ever used, but you cannot do sophisticated modelling inside the ball of mud. If you want to do sophisticated design and face that, draw the context boundary around the ball of mud and watch out for it. If you're working in the ball of mud, don't try to apply DDD.
• Not all of a large system will be well designed, but parts of the system can be properly designed. The trick is to figure out which parts of the system would really benefit from the design.
• Precision designs are fragile. Evans said “If you wanted to grow tropical orchids in London [...], they would start looking a bit yellow in September and in October they would be looking very poor. And yet you can do down to the flower shop and buy them any day. [...] They grow them in a greenhouse. Precision design requires a sheltered environment. [...] If you ignore that, you're wasting your time because the design will not be able to survive”. A very useful way to achieve this is to introduce an anti-corruption layer.
• Building blocks (value objects, entities, factories, repositories, services) are over emphasised.
• There is another important building block that needs to be added to that list: Domain Events. They can represent the state of entities at a given time when an important event occurred and decouple subsystems with event streams. Domain Events give us clearer, more expressive models in those cases. In addition, utilising Domain Events correctly enables us to apply DDD to enable high-performance of systems.
• Aggregates turned out to be one of the most difficult patterns to apply. There was an over-emphasis on access rules within aggregates (nobody can hold a reference to things within an aggregate apart from the aggregate root). A much more useful view at aggregates is to look at them as consistency boundaries for transactions, distributions and concurrency. Discovering contention points especially for performance might give ideas how the model should be changed, giving us insight on which things need to be seen and accessed in isolation. Evans said: “In stead of ad-hoc deciding to leave parts outside of transactions or boundaries, we want to use that and understand our model better”. Aggregates should be boundaries of consistency which you can trust.
• Aggregates should also be viewed from the perspective of being a “conceptual whole” — they should reflect what designers see as a single thing. Making a distinction between properties and invariants that apply to an aggregate as a whole and to the aggregate root as an object is important. Evans gave an example of the stem, berries and a grape. The stem is the root of an aggregate, berries are objects in the aggregate but the grape as a whole is an aggregate. The weight of the grape is a property of the whole aggregate (grape), not of the aggregate root (stem). Clearly isolating these aggregate properties and invariants allows us to model and implement them efficiently.
• Large scale structures just don't come up very often. Evans said: “If I was writing the book today I would probably leave this chapter out”. Other strategic design patterns are much more important.
• To succeed with domain driven design, teams require an iterative process and access to domain experts.
• Context mapping can be described step-by-step:
  1. What models (or big balls of mud) do we know of? (draw blob for each and name it.)
  2. Where does each apply? (define boundary in words.)
  3. Where is information exchanged (Draw connection.)
  4. What is the relationship?(upstram/downastream/partner? etc)
  5. repeat thinking about what have we missed until everything is drawn up
• SOA has made the definition of the word “service” as something that has complicated machinery which distributes applications. In DDD, the word means how do you break down applications and identify parts that “do things for you” contrasted to “being something”. This language difference causes a lot of confusion.
• SOA service interfaces must be defined in some context. Services cannot stand on their own. Evans said: “Anything that means anything has to be in some context”. Service internals belong to a context as well, but not necessarily the same context. Lots of nice services take a ball of mud and hide it from you and provide a nice interface and a clear language. In that case, the service interface is not in the same context as the implementation of the service. SOA service interfaces are often used to mark up context boundaries.