Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News The Importance of Patterns in DDD

The Importance of Patterns in DDD

This item in japanese


There are lots of patterns outside of Domain-Driven Design (DDD) that are important to know, Cyrille Martraire noted in his presentation at the recent DDD Europe Conference in Amsterdam when discussing the importance of patterns.

Ward Cunningham is well-known for developing the first wiki, but he was also one of the first to describe patterns. The first set of patterns was about information integrity, and Martraire notes that these early patterns were analysis patterns and described how to look at a business domain to better understand it. One example is Exceptional Value which makes it possible to write code as a business domain statement by removing all need for special case handling like dealing with illegal or zero values. Another pattern that he has found particularly interesting is Diagnostic Query, a pattern which suggests that an object should be able to describe how it reached its current state, a diagnostic ability that replaces the need for logging and debugging. A Money object with a value of 100 EUR could then describe that the amount came from adding a certain amount of GBP with an amount of USD.

Another source of patterns is the Design Patterns book by the Gang of Four, from the mid-90s. Of these patterns, Martraire finds four to be extra useful for modelling domain concepts and their relationships:

  • Composite for composing objects into tree structures and letting a client treat individual objects and compositions uniformly.
  • Interpreter for evaluating sentences in a language.
  • Flyweight that uses sharing to support large numbers of fine-grained objects.
  • Strategy for separating algorithms themselves from their usage.

Early in his career Martraire also discovered Martin Fowler’s book Analysis Patterns. From this book he learned a new set of patterns that came from retail banking, medical care and measurements. He believes that by learning many patterns and digesting the principles you will be able to apply them in new domains. However, to get a deeper understanding he emphasizes the importance of following the evolution of patterns and ideas over time, not just learning the state of today.

If you’re not already aware of all these patterns, Martraire questions if you are serious about design; perhaps you are too focused on the latest technology. One example is event sourcing which he too often has seen being used as the default style, which makes things unnecessarily complicated in cases where a simple CRUD model would be sufficient. Spend more time inside the domain model, and if you find design an issue, do it more often. If you prefer new projects Martraire believes you will end up with models that you don’t understand, and if you look at them later on you will see that they all are CRUD models. To practise your skills and to get into more complex models you should look at mature legacy systems where you may find deep domain models.

Martraire is currently writing a book about living documentation, describing how to use annotations to create documentation of DDD concepts, patterns used and other design concepts directly from the code.

Rate this Article