Domain Driven Design – Part II : The Building Blocks of a Model-Driven Design
October 6, 2006
Q & A: In what way are these patterns much more specific to business computing than those in the first reading?
The patterns in Part II are more specific to business computing because most of them are persistence aware and assume a layered architecture. Both those characteristics are common among business computing systems.
Interesting excerpts from Part II:
“Developing a good domain model is an art. But the practical design and implementation of a model’s individual elements can be relatively systematic. Isolating the domain design from the mass of other concerns in the software system will greatly clarify the design’s connection to the model. Defining model elements according to certain distinctions sharpens their meanings. Following proven patterns for individual elements helps produce a model that is practical to implement.”
Introduction
The previous part of the book introduced the patterns UBIQUITOUS LANGUAGE, MODEL-DRIVEN DESIGN and HANDS-ON MODELERS which target the central goal of having a common domain model which is consistent with the UBIQUITOUS LANGUAGE and implementation. This part of the book introduces fundamental and standard patterns which team members can use to produce such a model.
Chapter 4: Isolating the Domain
In most software projects, the code that directly deals with accomplishing domain activities is usually accompanied by code for many other supporting functions like user interface and persistence. If the domain code is not isolated from the other code, it becomes very had to reason about the domain code and maintain consistency with the domain model. This chapter introduces the LAYERED ARCHITECTURES pattern which can be used to isolate the domain from the rest of the implementation. This is a widely used pattern and the most commonly used layers are User Interface/Presentation Layer, Application Layer, Domain Layer and Infrastructure Layer. The most necessary layer is the domain layer. This layer isolates the domain code from the rest of the implementation and allows developers to focus on expressing the domain model accurately and hence enables MODEL-DRIVEN DESIGN.
This chapter also introduces the SMART UI anti-pattern in which the domain code and user interface code are not separated. The author says that this might be suitable for some (usually small) systems without complex domains. It is called an anti-pattern because it does not enable MODEL-DRIVEN DESIGN.
Chapter 5: A Model Expressed in Software
This chapter discuses the elements that can be used to build an implementation of a model and the patterns which can be used to define those elements. The patterns are:
ENTITY: An object that is distinguished by its identity rather than its attributes. The author provides the great example of transactions in a banking system. Even if two transactions for the same amount are executed at the same time, they are still considered distinct. ENTITY objects usually have a life cycle through which they go through different states.
VALUE OBJECT: An object that is distinguished solely by its attributes. VALUE OBJECTS don’t have life cycles and should therefore be immutable.
Associations: A relationship between elements (ENTITY objects and VALUE OBJECTS) which can have various traversal directions and multiplicities.
SERVICE: A stateless operation that does not conceptually belong to an ENTITY or VALUE OBJECT.
MODULE: A higher level domain concept which groups together of a set of cohesive elements. MODULE objects are used to present higher level relationships in the domain model and they can be seen as sub models which hide interior details from external observations and on the other hand allow people to look at a particular part of the model without being overwhelmed by the details of the entire model. MODULE OBJECTS should have low coupling and high cohesion.
Chapter 6: The Life Cycle of a Domain Object
This chapter introduces three patterns that can be used to manage domain objects with complex life cycles. They are:
AGGREGATES: Used to group ENTITIES and VALUE OBJECTS together and define clear boundaries around them.
FACTORIES: Used to manage the beginning of life cycles. FACTORIES are responsible for the creation of complex objects and AGGREGATES.
REPOSITORIES: Used to manage the middle and end of life cycles. REPOSITORIES are responsible for providing the means of finding and retrieving persistent objects and encapsulating the infrastructural complexity of those operations.
