Models are used to solve specific problems, and generally we only talk about “is the model more useful for the domain”, not which model is better.

Strategic design in domain design

  • Common language: use one language to clearly explain the various problems and their solutions from the discussion of domain experts to the code. However, there are many problems, and each problem has its own common language. Therefore, it is hoped that in the implementation of software, there is only one language within the boundary through a boundary
  • Context: Settings used to determine the meaning of a word or statement
  • Bounded contexts: Languages have their own contexts, and we want to manage the order of each and avoid chaos, so we introduce bounded contexts to help us make elegant models in real projects
  • Domain: knowledge (cognitive, business) or area of activity
  • Models: System-wide abstractions from a domain-selected perspective
  • Context mapping: Multiple bounded contexts are more or less related to each other. To understand the global view, you can map the current situation by describing the points of connection between them in an appropriate way, specifying the transformations required for all context communication

If you want to build an online selling system, you basically need an e-commerce system to sell things online, a supply chain to ensure the supply of goods, and a data analysis system to predict supply. The following context mapping can be made:

Each bounded context in the figure is a solution for a particular domain that we can implement software to solve, and the domain itself is the business described

From this perspective, we can divide the domain into problem space, where we think about the challenges facing the business, and solution space, where we think about how to implement software to solve those challenges

If you look closely at e-commerce, you can find orders, goods, payments, activities and other businesses, which can be called sub-domains of e-commerce

  • Core domain: the main factor of business success and the lifeblood of business
  • Support subdomains: Focus on one aspect of the business
  • Generic subdomains: Apply to the entire business system

From a global point of view, there are many connections between different bounded contexts, and they communicate with each other, but we do not want knowledge from different domains to “leak” to other domains and bring more cognitive costs

  • Open host/messaging: Defines a protocol to facilitate communication between different boundaries
  • Coating: Escape between different models

The effect of the coating can be seen in the following view. When you enter the interior of the house from the outside, there is a place to change your shoes, which can be regarded as the coating

Tactical implementation in domain design

  • Entities: Have unique identifiers by which to distinguish different entities. It contains properties, and the behavior of properties
  • Value object: A concept that measures or describes something in a domain whose properties form a conceptual population and whose values are immutable
  • Domain service: When an operation or transformation process in a domain is not the responsibility of an entity or value object, put the operation process into a separate interface, the domain service
  • Domain events: Events occurring in the current domain that are of interest to other domains
  • Aggregation: A collection of related objects that are modification units of data and have their own aggregation roots and boundaries that are consistent with the boundaries of a transaction, that is, only one aggregation instance is modified by a transaction, outside which final consistency is generally considered
  • Modules: Consistent with the concept of domains, named in a common language, used to organize cohesive domain objects, with less cohesive or non-cohesive domain objects placed in different modules
  • Factory: Interface that encapsulates all complex assembly operations
  • Repository: Global access that encapsulates the actual storage and query behavior and provides repositories only for aggregations that really need direct access, allowing customers to focus on the model

Domain-driven design is used in hierarchical models

Domain-driven design does not require the use of a specific architecture. It can be applied to a variety of architectures. Taking the layered model as an example, an application can be divided into:

  • User interface layer: Handles user displays and user requests, without any domain or business logic
  • Application layer: A thin layer that is mainly used for coordinating operations on domain objects and, if an ACID database is used, for controlling transactions to ensure atomicity of commits
  • Domain layer: Handles business logic and publishes domain events
  • Infrastructure layer: Reusable infrastructure for persistence, messaging mechanisms, and so on

How do I render a domain object into a user interface display? How are user actions reflected in the domain model?

  1. DTO: Data Transfer Object, which contains all properties of the display. The drawback is that you may need to create classes that are very similar to the domain Object, fully coupling the domain Object and the interface presentation
  2. DPO: Data Payload Object, which contains all aggregate references. The presentation component obtains aggregate references through the DPO and accesses the desired attributes from the aggregate
  3. Presentation model: Decisions are made based on state, rather than one-to-one mapping with aggregation, so that state changes and decisions are placed in the presentation layer, separate from the view. For example, whether a component can be editable, true means editable, false is not editable, but true/false is assigned by the presentation layer

reference

Eric Evans: What is DDD? Eric Evans on Bounded Context

Eric Evans, Domain-Driven Design: Coping with Software Core Complexity

Vaughn Vernon’s book “Implementing Domain-Driven Design.” Martin Fowler presents the model