These reviews
The previous article introduced the first part of the book, “Applying the Domain Model,” which presents the basic goals for domain-driven development that drive the practices discussed in the following sections. The first part also defines some terms and gives the general meaning of using domain models to drive communication and design.
We learned the following patterns:
- UBIQUITOUS LANGUAGE
- MODEL DRIVEN DESIGN
- Hands-on MODELER
This article focuses on the second part, “Building Blocks for Model-driven Design,” by distilling some of the core best practices in object-oriented domain modeling into a set of basic building blocks. This part is about bridging the gap between the model and the actual running software.
This article summary
From the previous article, we learned that models and code implementations should be closely linked. In this article, we will introduce a set of Building Blocks for Building domain models that help bind models and programs together.
Model-driven design(MODEL DRIVEN DESIGN) navigation diagram
How are parts outside the domain model treated
The part of a software system that deals with business logic is a small part of the total software, and this part is the domain model that we focus on. There are also a large part of software unrelated to the domain model, such as visual presentation of software, network communication, user data persistence, data format transformation, etc., which are essential to the software system but not included in the domain model. How should we treat the parts of the domain model? Author Eric tells us:
This consistency (that is, the consistency of software and model concepts at the domain level) is not possible if the domain logic is mixed with other concerns in the program. Independent domain implementation is the premise of domain-driven design.
Early object-oriented coding, often in the same object to write user interface, database access code. Some of the business logic is embedded in interface components or database scripts. It is difficult to view and analyze domain-specific code. Changes to the interface may also result in changes to the business logic. This makes it difficult to achieve consistent model-driven objects. To develop programs that implement complex tasks, separation of concerns is essential.
Domain objects should focus on how to express the domain model without having to worry about their own display and storage, or managing application tasks, etc. This makes the model rich enough and clear enough in structure to capture basic business knowledge and use it effectively.
The author introduces a commonly used Layered Architecture. He points out that most software systems employ Layered Architecture, but the specific Layered schemes are different. The value of layering is that each layer focuses on only one aspect of the problem, making the program design more cohesive. There are a lot of layered schemes, and applicable to the domain DRIVEN DESIGN of layered schemes, the need to separate the domain layer, which is the key to achieve MODEL DRIVEN DESIGN (MODEL DRIVEN DESIGN). The author gives a hierarchical scheme as a reference:
The basic principle of the layered architecture pattern is the unidirectionality of dependency, that is, the upper layer can depend on the lower layer, but the lower layer cannot depend on the upper layer. The well-known MVC pattern (Modle-view-Controller) is the earliest hierarchical scheme that separates the user interface layer, application layer and domain layer. Author Eric gives an example of an online bank transfer. The user can select two accounts and enter the amount to perform the transfer. Start the transaction at the application layer and invoke the credit and debit methods of the domain-layer Account object. The technology infrastructure layer provides transaction management capabilities and data persistence.
The interaction of the domain model in the example is straightforward. As can be seen from this example, separating the domain layer and focusing on the design of the domain layer can better draw the model that expresses the domain rules.
Whether the domain layer can not be separated
The author introduces the Smart UI pattern, which implements all logic in the user interface. It sounds like heresy, but there’s a reason for it. The authors quote:
SMART UI also has its advantages, and in some cases it works best.
For example, the development efficiency of using Smart UI is high, and the skill requirement of developers is low. Of course, the code is hard to reuse and is not suitable for developing complex features. SmartUI is a viable option for a project that only needs to provide simple functionality, mainly data entry and display, with few business rules involved. But it is not compatible with model-driven design, so SmartUI is often used as an anti-pattern when discussing domain models.
Eric also mentions Transaction Script, a pattern first described by Martin Fowler in PoEAA. In this pattern, the user interface layer is separated, but the domain model is not abstracted. It seems to be somewhere between Smart UI and Layered Architecture. It is suitable for relatively simple business logic system, only need procedural script can be implemented. In fact, many of the projects I’ve worked on have followed this pattern. But it clearly does not support domain-driven design.
Layered Architecture is not the only Architecture suited to domain-driven design, The Hexagonal Architecture and Robert Martin’s The Clean Architecture both naturally support domain-driven design. The authors note:
An architecture that isolates domain-specific code, resulting in a cohesive domain design while keeping the domain loosely coupled to the rest of the system, may support domain-driven design.