Domain-driven application architecture practice

A suitable application architecture can not only promote the development of the project in a good direction, is easy to maintain, but also guides team members to collaborate effectively.

DDD is to drive the implementation of the application architecture from the perspective of the field. Next, we will introduce a landing solution.

Architecture layering

First of all, in terms of architecture level, while following the layered architecture pattern of DDD, combined with the shape of the hexagonal architecture, a new layered architecture pattern is formed. As follows:

insert image description here

The responsibilities of each level are as follows:

The adapter layer (adapter) is the entrance of system traffic, and distributes requests to the application layer to process specific application logic. This layer covers business interface requests, batch processing, messages, etc.
The facade layer (facade), as the facade of the system, is used to express the ability of the system to be exposed to the outside world.
The application layer (application) is the application logic orchestration layer of the system, which is used for cross-system or cross-aggregation business orchestration, and does not express core control capabilities.
The domain layer (domain), as the core of the domain-driven architecture, carries the core model, rules and services of the system, and is the brain of the entire system.
The infrastructure layer (infrastructure) is the base of the system, which supports the domain layer; the positioning of this layer is mainly the basic capabilities of the system (caching, storage, etc.), the integration of downstream support systems, and the anti-corrosion of domain capabilities.

architecture dependencies

In terms of project architecture, the dependency interaction between each component module is as follows:

insert image description here

engineering structure

After forming the landing mode of the architecture, the implementation of the project is also very important, which will affect the maintainability of the project and the implementation strategy of the coding landing stage. Let's take a look at an engineering structure that can be landed:

.
|-- app
|   |-- adapter
|   |-- application
|   |-- domain
|   |-- facade
|   `-- infrastructure
|       |-- acl
|       |-- dal
|       |-- integration
|-- bootstrap
|-- conf
`-- test

The meaning of each directory is as follows:

app: The directory where the engineering application stores the code, and the subdirectories are the different modules mentioned in the previous architecture layering
bootstrap: The starter of the application, as well as the configuration information of the application except the environment
conf: environment-related configuration information
test: project-related test code

In terms of engineering structure, the infrastructure layer is split according to responsibilities:

dal: database interaction module
integration: system integration module, such as integration with downstream systems, integration of other basic capabilities
acl: system anti-corrosion layer, anti-corrosion isolation between domain and basic settings

If you want to view more detailed information about the project structure, click ddla Architecture Engineering Specifications .

schema usage

Use the following maven command to replace the groupId, artifactId, version, package and other parameters with the values you expect. The version of the scaffolding (ddla-archetype.version) can be directly searched in the maven warehouse using groupId (ddla-archetype).

mvn archetype:generate \
    -DgroupId=com.lazycece.ddlademo \
    -DartifactId=ddlademo \
    -Dversion=1.0.0-SNAPSHOT \
    -Dpackage=com.lazycece.ddlademo \
    -DarchetypeArtifactId=ddla-archetype \
    -DarchetypeGroupId=com.lazycece.ddla \
    -DarchetypeVersion=${ddla-archetype.version}

open source address

https://github.com/lazycece/ddla