1. What is the structure
Broadly speaking, architecture is a combination structure, including product architecture and system architecture. A good architecture can make products and systems better presented, better iterated and maintained. A good architecture is evolved, and a good code is refactored.
We often hear nouns such as middle platform, platform, system, and application. What is the relationship between them before?
1) Application: It is the smallest granularity and is used to realize the functions of the business system. For example, microservices are popular now, and the applications that implement a business system generally include: web applications and service applications.
2) System: The systems mentioned here are all business systems. Generally, a business system is at least a complete commercial product. Such as sourcing system, bidding system, etc.
3) Platform: It is composed of multiple business systems. The capabilities of the platform are richer than those of a single business system. The platform provides relatively complete business capabilities in a certain field. For example, the procurement platform is composed of business systems such as sourcing and bidding. The platform is functional reuse, and generally only supports a single scenario, such as a large enterprise procurement platform, which only supports the scenario of large enterprise procurement.
4) Middle platform: On the basis of the platform, multiple scenarios are supported through extension points, which is business reuse. The procurement center can support the procurement of large enterprises, small and medium-sized enterprises, and individuals.
Each level has its own architecture (platform architecture, business system architecture, application architecture), and it also focuses on different things. Platform architecture and system architecture pay more attention to: the division of responsibility boundaries, deployment methods, and the application of new technologies (cloud access, microservices, etc.). The application architecture focuses more on the layering and design of the application itself. For example, layered architecture and DDD domain-driven design are more popular now , and application architecture will be the focus of this article.
2. Division of Responsibilities
The division of system boundaries is crucial to business architecture. The general principle is: division according to responsibilities. When a responsibility does not know which domain it is assigned to, an intermediary domain can be assigned.
By analyzing the use cases, the models in the same domain must interact a lot, and the cross-domain models must rarely interact. If you find that the cross-domain models interact a lot, it is likely that there is a problem with the division of domain responsibilities
3. Domain-driven design and its core components
Introduction to Domain Driven Design
What is Domain Driven? Domain-driven design is an idea that guides system design and development. It requires us to pay attention to business domain knowledge, understand domain knowledge, and be domain-oriented and model-oriented. Rather than technology-oriented, data-oriented design. Through continuous communication with business domain experts, in-depth understanding of domain knowledge, continuous iteration of system design, and then presenting a better domain model. A valuable domain model must not appear immediately, but needs to be obtained after an in-depth understanding of domain knowledge.
Why is Domain Design needed? The complexity of a software system often does not come from the technical implementation itself, but from the business itself, complex business processes and evolution.
The domain model needs to be understood by both technical and business experts. If domain experts cannot understand the domain model, then the model must be designed incorrectly. Domain modeling is not only about building entities, but also includes value objects, domain services, and implementation patterns. Design and implementation must be bound, and design and implementation should not be separated. When you see the domain design, you should know the system implementation mode. Otherwise, the implementers will not understand the domain design intent, the more the system implementation deviates from the domain design, and the data integrity of the domain model is difficult to guarantee. The entire domain design will be meaningless.
The domain model is not only an abstraction of the core concepts of the domain, but also can guide software development and implementation. Object-oriented design is the modeling paradigm used for most domain modeling.
Domain core components include domain objects and domain object lifecycle management. Domain objects include: entities, value objects, and domain services. Domain object life cycle management includes: factory, repository, aggregation. Both domain objects and domain object lifecycle management are core assets of the domain layer .
1) Entity: An entity can exist independently and be meaningful in business interaction, and requires the existence of a unique sign, and the unique sign has actual business meaning. For example, when shopping online, although the contents of the sent packages are the same, they are two different packages.
2) Value objects: generally only care about the content, do not care about the need for a unique identifier, and use aggregation as an additional attribute of the entity. For example, when a person draws with a brush, he only cares about the color, thickness and other characteristics of the brush, not which brush it is. In short, in the scene, if the content is exactly the same, it can be considered as the same object, it is a value object, otherwise it is an entity.
3) Domain service: Sometimes there will be some special operations in the domain, which do not belong to any entity or value object. At this time, domain services can be used. At this time, domain services are the best way to represent domain concepts. The parameters and return values of domain services should be models in the domain, and services should be stateless.
4) Aggregation: Aggregation is to take an entity as the aggregate root and aggregate other value objects as attributes. The aggregate root should be the smallest unit of modification/query, and must be modified/queried with the aggregate root as the unit. Aggregation generally refers to the relationship between entities and value objects, and association generally refers to the relationship between entities.
5) Factory: The main responsibility of the factory is to create objects and rebuild objects (rebuild the data queried from the storage medium into domain objects). The creation of complex objects belongs to the domain layer. It does not have to be realized through the object itself, but can be created through the factory. Factories are generally used to create complex object types that require generalization, and simple model objects can be created directly through constructors.
6) Repository: The main responsibility is the mutual conversion between objects and storage, and the type can be properly abstracted. It is not necessary for each model to correspond to a repository.
Best practice of DDD application architecture layering
1) Layered application architecture
2) Commercial capability
Through the assembly of capabilities in different fields (possibly across organizations and departments), certain business capabilities can be synthesized, and quick access through configuration + customization can speed up business iteration
4. Guiding ideology of domain-driven design
1) In the domain layer, the concepts of the domain must be used to express business logic, and all core domain logic is implemented based on domain components. Instead of directly relying on external implementations, and not exposing irrelevant interfaces to the outside world, the domain layer should be the key protection object.
2) The repository layer generally does not participate in transaction control.
3) Always pay attention to the design and responsibilities of the domain model, adhere to the SOLID principle of object-oriented design, and do not use domain objects only as data containers.
4) Try to traverse the database through the aggregate root to find the associated value object instead of directly traversing the value object. If you really need to skip the entity and directly traverse the value object, then you must consider whether the design of the model is unreasonable and whether the value object is necessary to be designed as an entity.
5) The entire design should be low-coupling and high-cohesion, including package design and division.
6) Software design must always fight against complexity, and leave complex design to the place where it is really needed. Domain modeling begins with simplifying associations . The association between models should be as less complex as possible. Those that can be associated one-to-many should not be designed as many-to-many associations, those that can be associated one-to-one should not be designed as one-to-many associations, and those that can be associated one-way should not be bidirectional. When simplification is not possible, consider whether you can add some appropriate and realistic conditions, which can reduce the complexity of the association. The more complex the association, the more difficult it is to guarantee the consistency of data, the more difficult it is to guarantee the stability of the system, and the complexity of system implementation will increase. If the relationship can be properly simplified, it also reflects a deep understanding of domain knowledge. Constrained associations can convey more knowledge and are more practical. Carefully simplifying and constraining model associations is the only way to domain-driven design
7) Design the data storage structure according to the needs of entities and value objects. Generally, 1-to-1 domain model related information can be stored in a data table, unless large fields are separated into different tables. 1-to-many data can only be separated into different tables. Database design should adhere to: make our data query and update more efficient, and ensure data integrity more securely.
8) In addition to accessing the associated objects in the aggregate through the aggregate root, it is not allowed to access other objects in the aggregate in any other way