Domain-driven design has three implications:

  • Collaboration layer

  • Architectural layers

  • Implementation layer

Collaboration layer

The collaboration layer emphasizes that requirements are not unrooted, but have their origins, often traced to business domains outside of technology.

Therefore, software development is not only software and programming, but the collaboration of various functions, is a process of co-design.

The common language built based on domain knowledge is an important way to ensure consensus among team members.

Software development process is an iterative process in which business domain knowledge flows to code realization, and then the software realized by code collects information feedback to update domain knowledge.

Each function has an obligation and mission to advance understanding and consensus in the business area.

Architectural layers

From business requirements to software implementation, it often involves many supporting, auxiliary, non-core related sub-requirements and sub-areas, such as code hosting, monitoring, knowledge base, project management platform, IM, operation and maintenance, etc.

Therefore, not all requirements are equally important, and we can divide requirements into core areas, supporting areas, general areas, and so on, according to our business areas or core goals of the business.

Technical resources are limited, should focus on core areas, and auxiliary, supporting, appropriate outsourcing or purchase of services provided by mature systems.

The software architecture implication of DDD is to identify and weigh which requirements should be implemented by the code itself and which should be implemented by other companies.

The part that realizes oneself, also have domain subdivision. Different development teams have different levels of knowledge of different areas. There are teams in charge of user/login/authentication, etc., who are more knowledgeable about the domain and are constantly updating their knowledge because they have the authority to source and define the domain. Other teams are reinventing the wheel, making it hard to stay engaged and keep up with new changes.

Therefore, how to divide the technical team and organize the domain collaboration between them is a test of the architect’s design level.

In fact, the centralization of domain knowledge and authoritative sources should be included behind the centralization of the centralization of domain knowledge and authoritative sources to reduce the phenomenon of repeated construction and insufficient investment.

Intuitively, it’s a matter of where and by whom the code is written. There should not be two different code implementations of the same domain knowledge and requirements. At the same time, it is difficult to ensure the integrity, consistency and continuity of domain knowledge by iterating codes with overlapping functions, which is reflected in various data or logic inconsistencies (bugs) in software.

The wrong software architecture and the organizational structure of the people behind it often cause the above problems systematically, which is an important inducement and signal leading to product failure.

Implementation layer

The code implementation of requirements is not arbitrary and should reflect the requirements and knowledge expression in the business domain as much as possible.

Algebraic Data Types (ADT) have good mathematical properties. Through Product Type, Sum type and Exponential type, coexistence, mutual exclusion and conversion can be expressed respectively.

The correct use of ADT to express the internal relationship of domain knowledge can make use of type-check ability of Compiler to cover and maintain domain knowledge in code earlier and more comprehensively.

Simply coding domain knowledge in object/class often makes code more difficult to maintain and has more potential for illegal states because they lack the ability to express mutual exclusion, requiring conscious and proactive verification every time state data is consumed. And every omission is a hidden danger.

Make illegal state unrepresentable, using a more expressive type system that makes illegal states difficult to represent and construct.

Make illegal operation unrepresentable, uses a well-designed type system and framework that makes it difficult to express or misuse illegal operations.

For example, operation/capability is more accurate and controllable through parameters than in global variables or modules. Modules are not arbitrary, and can access data and capabilities at will. Modules and code that are subdivided by domain should access only and related capabilities, not all capabilities. Reduce space for misuse, thus reducing the probability of multiple copies of overlapping code growing and spreading in the code base).

The theoretical basis of the implementation layer is curry-Howard Isomorphism, and the code and logic are isomorphic. The logical representation of domain knowledge can be isomorphic to its code representation.

This is the foundation of DDD. Code should reflect domain knowledge, and both should be synchronized in the medium of a common language. The isomorphic nature of code and logic makes synchronization possible.

The relationship between the three meanings

The collaboration layer is the core and authoritative, it is the design basis of the architecture layer.

The goal of the architecture layer is to efficiently support and meet the knowledge and requirements generated by the collaboration layer, and to arrange the distribution of code in the human organization structure (internal, external, middle stage, background, front stage, specific business sub-field development group, etc.).

The implementation layer is the concrete code expression under the guidance of the architecture layer. It should follow the software planning of the architecture layer, avoid repetitive, inconsistent, and unsustainable code maintenance, and adopt focused, authoritative source, compiler type checked, and sustainable iterative code implementation.

When the collaboration layer changes, the human organization structure often changes, the software architecture layer needs to adapt to this trend and make reasonable adjustments, so the code implementation layer also changes.

Collaboration layer > Architecture Layer > Implementation Layer