preface

This article does not talk about the common concepts in DDD, trying to use a progressive way to express my understanding of DDD, this article as a medium for more communication and more thinking to promote each other. I hope to give you an understanding of the nature of DDD, what is DDD? How does DDD land?

While WE haven’t talked about what DDD is, let’s be clear about what DDD is not: DDD is not a four-tier, hexagonal architecture. DDD is used with hexagons and four layers when landing, that’s all.

Axon framework

Why start with Axon

Axon framework includes DDD ideas, for everyone to understand DDD to get twice the result with half the effort, the premise is not to fall into the AXon framework itself, AXon framework is highly abstract and complex, and java8 syntax tracking debugging is difficult, just need to learn axon provided by the application demo. Another book, Microservices Architecture Design Patterns, the axon framework is perfectly executed in the first seven chapters of the book. If you’ve studied Axon and you go back to the book Design Patterns for Microservices Architecture, it’s very abstract and Axon is very concrete.

Axon is introduced

The Axon framework is a framework for building evolutionary, event-driven microservices based on DDD domain-driven design, command-query responsibility separation (CQRS), and event traceability. Axon also includes the idea of hexagonal architecture that allows developers to focus more on the business and adapt to complex business changes.

If I were to summarize Axon, Axon tries to keep all technical implementation and details out of the way, leaving developers to focus on requirements analysis and design, which they then translate into code into the Axon framework.

Axon also has some features: All in memory (hot data, somewhat different from redis cache), no developer concern about concurrency (all business code is developed in a single thread), no concern about local and distributed transactions, and high performance. I’m just going to mention the internal implementation of Axon.

A brief introduction to several ideas in Axon

CQRS

CQRS separation is essentially framework level, speaking, reading and writing, and reading ten thousand times also does not affect the data change of state, in the process of business development we can pay more attention to the increase of the change of the state of data deletion (attention) when query performance optimization, the domain model in DDD also pay more attention to the increase of the change of the state of data deleted, so the Axon framework CQRS used with DDD thought.

Another point is that in Axon, the transaction is executed successfully as long as the add, delete, or change is successfully executed in memory, and the drop of the add, delete, or change can be followed slowly and asynchronously. This is also a way in which the Axon framework can be shielded from all technical implementations to allow business people to focus more on the business.

Event source

Event traceability is a way to store application state from the history of events that occurred in the past. The current state is rebuilt from a complete history of events, where each event represents a change or fact in the application. For example, the current balance of a person’s bank account is determined by all previous income and expenditure in that account. We can replay every previous transaction and get the current account balance.

Hexagonal structure

The hexagon is essentially an adapter pattern, which is often used both in our business development process and in the Axon framework itself. For example, in this project we used the Axon framework to send A message from service A to service B. Axon provides several MQ options for you to choose from, without requiring the business person to know which one is being used. Here’s a joke: HEXagon architecture is a word I think is problematic and can’t be called architecture.

In the Axon concept

Axon includes Command, Command Bus, Command Handler, @Aggregate(Domain), Event, Event Handler, Event Bus, Saga, Query, Query Handler. Among them, the first black one belongs to C in CQRS, and the last two belong to Q. Aggregate(Domain) is the basis and core of C implementation.

DDD

Study the following examples provided by Axon officials first, and then come back to understand the ideas and concepts.

Axon learning examples

Just look at the above ideas and concepts, in fact, to understand Axon, DDD help not much, directly run the demo to experience Axon operation logic. You can quickly understand the concepts mentioned above. Download and start AxonBank project, visit: http://127.0.0.1:8080/ This demo can create a bank account, save money, withdraw money, transfer money, query the transfer record four functions. It’s important to break the point and get a feel for axon’s logic, otherwise it’s hard to understand Axon.

Run AxonBank Demo with the problem: 1, The difference between command and Event scope and responsibility. 2. The role of Saga in the business process. 4. When did the data enter the database? 5. Consider which of the axon concepts mentioned above corresponds to the domain layer of the four layers, the APP layer.Copy the code

So let me draw the Axon transfer implementation

Looking at this diagram, many people would say it’s a flow chart, but it actually has a more technical term called an activity diagram in UML. Flow diagrams are biased towards processes, activity diagrams are not only processes but also aggregates,Axon again suggests breakpoint debugging.

DDD domain driven design

Purpose of coding

Think about the question, what is the purpose of coding? Coding is meant to solve real problems, and the first problem we face to solve real problems is how to map business to code. Mapping business to code takes three big steps. First you need to understand the business (requirements analysis), then design, and finally landing (development, deployment, and operation). Regardless of the development model, understanding the business and design is the most important of these three steps.

Domain-driven design

Domain driven design focuses on domain and driver. Domain and driver correspond to understand the business and design in the three steps of development process respectively. What is a domain? There are several driving designs, and how does a domain driver drive?

What is a domain

Coding is about solving real problems, and we have a lot of specific problems to get things done, and we tend to categorize them. For example, if we want to be an e-commerce (industry), the problems we face are users, commodities, selection, ordering, payment, delivery and after-sales. Operation also needs permissions, logs and monitoring. For example, to be a financing platform (in the industry), we are faced with problems such as users, investors, risk control, borrowing money (placing orders), lending money and paying back money. Operations also require permissions, logs, and monitoring. Each of the above questions is a specific area. Generally we have one microservice for each domain. There are many articles on domains (business domain, support domain, generic domain) and other concepts that you can learn on your own.

Drive design mode

There are many ways to drive, the more common is database driven design. Database driven design, domain driven design. They are both landing ways of mapping business to code, but with different concerns. The database driver takes precedence over how to encode data. Domain-driven design prioritises how to code and, finally, how to store the data. The storage of data is a technical thing and the logical code is a business thing, which is why we keep hearing about the domain drive to focus more on the business. Database-driven design: get the requirements or prototype, many people directly according to the prototype began to design the table, finally began to write code, the development process found that the table is not reasonable prototype is not reasonable. Domain-driven design: in the face of a problem, first understand the requirements and conduct requirements analysis, then design specific classes (aggregation), specific methods (input), specific logic (saga), and finally consider the landing of data. Think about how to understand requirements, how to design concrete classes, saga, and what tools to use.

Requirements analysis and design

Here is an example from DDD book: Take flight control system as an example to illustrate how to conduct requirements analysis and design. Please refer to “Building Domain Knowledge” and “Creating a Common Language” in “Domain-Driven Design Lite” (download by yourself, these two parts are essential, the other parts are not necessary to see). After reading this, many people will say, isn’t this the process of communication? Yes, the process of communication. How to improve the efficiency of communication so that both sides can understand each other and avoid ambiguity? # Eric Evans proposed: limited context, universal language. Context limitation is used to define the scene in the process of communication. For example, when I say open an account, I need to define a scene first: for example, when I say open an account to a bank teller, the meaning of opening an account to a broker teller is different. A common language is a language that is understood by both parties without ambiguity. Eric Evans just mentioned these two concepts, especially the common language, but did not propose a tool for us to use during the requirements analysis and design phase. The UML Unified Modeling Language is recommended.

My domain drives the process of understanding

Five years ago, when I learned DDD, I first came into contact with axon framework. I felt that AXon was too powerful to handle complicated business and had strong scalability. At that time, I believed that only AXON (congestion model, object-oriented programming) was the correct way to implement DDD. We now think of DDD as microservices + business combing + object-oriented thinking. There is not much relationship between the framework adopted, whether it is hyperemic, process-oriented or object oriented, and whether it is stratified into three or four layers. Only abstract classes, business processes and state reversal can be designed in accordance with the domain mode in the design stage. As an aside: Although Java is an object-oriented language, most corporate developers still define beans and stateless services. There is no difference between defining structures and functions during C development, so most corporate Java code is still procedure-oriented.

How to land DDD

DDD design steps

Because DDD: micro services + business combing + object-oriented thought the first step: divide micro services according to various domains, a service can contain one or more domains. Even if you haven’t heard of DDD, you have all been exposed to microservices. There is no need to talk about the second step: business combing + object-oriented, business combing first and then object-oriented abstract class, which is a repeated process. We don’t pay much attention to the read interface in this process. Specific operations: In the process of business communication, we record nouns and verbs, names are generally abstracted into aggregations (Java classes) and verbs are abstracted into methods (with exceptions), and draw activity diagrams (UML) and state diagrams, etc. In this process, we can use UML tools for the third step: A data table is designed to accommodate aggregations, entities, and value objects. The relationship between aggregations and tables is not one-to-one; one aggregation may correspond to multiple tables.

DDD design landing tool

Domain modeling tool: UML Unified Modeling Language: including class diagram, use case diagram, state diagram, sequence diagram, collaboration diagram, activity diagram and so on ten kinds. The class diagram modeled in UML is the congestion model. State diagrams describe state reversals. Use case diagram requirement analysis is used to comb functions in the early stage, marking one function by one with ellipses. Sequence diagrams generally identify the order of execution from one class to another. Activity diagram A special flow chart containing object information.

DDD design ground architecture

The above design process is independent of the specific technology stack, so should we choose the hyperemic model or the anaemic model? Which technology architecture is used to land DDD? A: As long as we do requirements analysis and design implementation according to DDD thinking during the requirements and design phase, we are already using DDD thinking. Specific is the choice of hyperemia model, anemia model landing theoretically speaking. Congestion model: If congestion model is selected, we can use Axon frame landing. The benefits of using the Axon framework Even if you don’t learn DDD ideas in depth, using the Axon framework will automatically implement DDD. In addition, the class diagram and activity diagram produced in DDD design phase can be perfectly mapped to Axon’s aggregation root and Saga. Anaemic model: If we choose anaemic model, we split the class diagram produced in DDD design phase into anemic beans and stateless services in a process-oriented way. UML activity diagram is not hardcoded to call method by method in the saga way. Three or four tiers: I believe in sorting out the business in DDD fashion and designing the right class diagram activity diagram, whether axon or any other framework, whether three or four tiers. So why do a lot of DDDS emphasize layering? Layering is a discipline and discipline: the idea of layering predates ideas like microservices, DDD, etc. Even if everyone understands DDD, it is a problem that everyone’s coding style is not uniform, so there are three or four layers of engineering structure, each layer of responsibility is clear for later development and maintenance. Have the opportunity to write an article about the layers and specific responsibilities of each layer.

DDD landing difficulties

First, inertia, because the previous training is database driven development, it is difficult to change to domain driven development. Second, time. It may take longer to make detailed requirements and design, and finally map the design into code.