- "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."
- "Elaborate models can cut through complexity only if care is taken with the fundamentals, resulting in detailed elements that the team can confidently combine."
Chapter 4: Isolating the Domain
- "The part of the software that specifically solves problems from the domain usually constitutes only a small portion of the entire software system, although its importance is disproportionate to its size. [...] We must not be forced to pick them out of a much larger mix of objects [...] We need to decouple the domain objects from other functions of the system, so we can avoid confusing the domain concepts with other concepts related only to software technology or losing sight of the domain altogether in the mass of the system."
- Layered Architecture
- "In an object-oriented program, UI, database, and other support code often gets written directly into the business objects. Additional business logic is embedded in the behavior of UI widgets and database scripts. This happens because it is the easiest way to make things work, in the short run.
"When the domain-related code is diffused through such a large amount of other code, it becomes extremely difficult to see and to reason about. Superficial changes to the UI can actually change business logic. To change a business rule may require meticulous tracing of UI code, database code, or other program elements. [...] [A] program must be kept very simple or it becomes impossible to understand." - Most successful architectures use some version of these four conceptual layers:
- User Interface (or Presentation Layer)
- Responsible for showing information to the user and interpreting the user's commands
- Application Layer
- Defines the jobs the software is supposed to do and directs the expressive domain objects to work out problems.
- Domain Layer (or Model Layer)
- Responsible for representing concepts of the business, information about the business situation, and business rules.
- Infrastructure Layer
- Provides generic technical capabilities that support the higher layers.
- "Partition a complex program into layers. Develop a design within each layer that is cohesive and that depends only on the layers below. Follow standard architectural patterns to provide loose coupling to the layers above. Concentrate all the code related to the domain model in one layer and isolate it from the user interface, application, and infrastructure code. The domain objects, free of the responsibility of displaying themselves, storing themselves, managing application tasks, and so forth, can be focused on expressing the domain model. This allows a model to evolve to be rich enough and clear enough to capture essential business knowledge and put it to work."
- Relating the Layers
- Layers should be loosely coupled, with dependencies only in one direction.
- Upper layers can use or manipulate elements of lower ones by calling public interfaces
- When a lower level needs to communicate upward (beyond answering a direct query), patterns such as callbacks or observers should be used.
- Architectural Frameworks
- "When infrastructure is provided in the form of services called on through interfaces, it is fairly intuitive how the layering works and how to keep the layers loosely coupled."
- Some technical problems call for more intrusive forms of architecture.
- Architectural frameworks often require the other layers to be implemented in very particular ways.
- "The best architectural frameworks solve complex technical problems while allowing the domain developer to concentrate on expressing a model. But frameworks can easily get in the way, either by making too many assumptions that constrain domain design choices or by making the implementation so heavyweight that development slows down."
- "A lot of the downside of frameworks can be avoided by applying them selectively to solve difficult problems without looking for a one-size-fits-all solution."
- The Domain Layer is Where the Model Lives
- "The "domain layer" is the manifestation of [the domain model] and all directly related design elements. The design and implementation of business logic constitute the domain layer. In a model-driven design, the software constructs of the domain layer mirror the model concepts."
- The Smart UI "Anti-Pattern"
- "Many software projects do take and should continue to take a much less sophisticated design approach that I call the smart UI. But smart UI is an alternate, mutually exclusive fork in the road, incompatible with the approach of domain driven-design. If that road is taken, most of what is in this book is not applicable."
- If a project needs to deliver simple functionality, dominated by data entry and display, with few business rules, and the staff is not composed of advanced object modelers, it may warrant using the smart UI pattern.
- Other Kinds of Isolation
- "Unfortunately, there are influences other than infrastructure and user interfaces that can corrupt your delicate domain model."
- Chapters 14 and 15 will deal with a number of these issues.
