Domain Driven Design – Chapters 10 to 13
October 12, 2006
Interesting excerpt:
“The ultimate purpose of software is to serve users. But first, that same software has to serve developers. This is especially true in a process that emphasizes refactoring. As a program evolves, developers will rearrange and rewrite every part. They will integrate the domain objects into the application and with new domain objects. Even years later, maintenance programmers will be changing and extending the code. People have to work with this stuff. But will they want to?”
Introduction:
These chapters focus on concepts that complement deep models by helping developers develop implementations that enable refactoring and iterative refinement and allow the continuous synchronous improvement of the domain model and implementation. Chapter 10 introduces patterns that contribute towards a supple design, chapter 11 is about applying analysis patterns, chapter 12 discusses design patters and chapter 13 is about refactoring towards deeper insight.
Supple Design:
Supple design is essential for the successful evolution of a system. Without a supple design, the system becomes more unwieldy with every change. In this chapter the author introduces the following patterns that contribute towards a supple design:
- INTENTION-REVEALING INTERFACES
- SIDE-EFFECT-FREE FUNCTIONS
- ASSERTIONS
- CONCEPTUAL CONTOURS
- STANDALONE CLASSES
- CLOSURE OF OPERATIONS
Analysis Patterns:
The author presents Analysis patterns as higher level patterns which encapsulate previous solutions to common problems at the level of responsibilities or relationships between domain objects. They can apply to a particular domain or multiple domains. The author quotes the book “Analysis Patterns: Reusable Object Models” by Martin Fowler multiple times. The main message that can be derived from the chapter is that an Analysis pattern will seldom provide an out-of-the-box solution to a problem; instead it will provide a good starting point from which a suitable solution can be built.
Design Patterns:
The author presents Design patterns as patterns which provide solutions to technical i.e. non domain problems. Design patterns can therefore be applied across most domains since they are domain agnostic. Some design patterns can be used as domain patterns by changing perspectives. The author gives the examples of POLICY/STRATEGY and COMPOSITE. Some others cannot be used as domain patterns, for example FLYWEIGHT.
Refactoring Towards Deeper Insight:
In this chapter the author presents a broader context for the process of refactoring. The author presents the following three things to focus on:
- Live in the domain.
- Keep looking at things a different way.
- Maintain an unbroken dialog with domain experts.
The source of refactoring is some dissatisfaction with the domain model. This dissatisfaction may not necessarily stem from bad code. It could be that new requirements are not jelling naturally or that the UBIQUITOUS LANGUAGE seems disconnected from the domain experts. The timing of the refactoring is important and the author presents the following clues for when refactoring should be performed:
- The design does not express the team’s current understanding of the domain.
- Important concepts are implicit in the design (and you see a way to make them explicit).
- You see an opportunity to make some important part of the design suppler.
Sometimes when a huge gap/change in the domain model is recognised, it might seem like a crisis, but the author suggests that these instances should be looked at as opportunities to perform valuable refactoring that provides deeper insight.
