Domain Driven Design (3)

DDD and microservice coding practice

4. Event storm

4.1 Four-color prototype/color modeling

Four-color prototyping/color modeling

Define 4 types of stereotypes, representing objects of different stereotypes in different colors in UML:

1. Party, Place, Thing Party: the Place where the event takes Place, such as a warehouse or a retail store Thing classes are those that identify individual items such as individual cars, airplanes, DVD’s, books, pieces of equipment, etc. Literally, thing should refer to a specific item in the event. For example, in a customer’s purchase event, thing may not refer to an order, but a specific item in the order, such as books, clothes, etc
Role an abstraction of the behavior and manner of participating in a party, place, thing
Moment-Interval models something that one needs to work with and track for business and legal reasons, something that occurs at a moment in time or over an interval of time. Refers to business activities, objects, etc., which need to be operated, recorded and tracked due to business needs and legal reasons, such as sales, orders, reservations, flights, meetings and itineraries, etc
For example, products have various basic attributes, but there are big differences among different types of products. For example, when making e-commerce system, different types of goods, such as books, clothes, glasses, etc. There are big differences in front desk purchase process, back-end order processing process, financial accounting treatment, inventory management method, after-sales service principle and other aspects. These differences are designed into additional description attributes of products according to product types, which are called description. The effect is that when you see the main object of the product, You can clearly know what he stands for, and his other attached information is in description. For the most part, you’re probably using product base properties, just the product master object; Only the part involving difference processing needs to care about the data related to description. Therefore, it is divided into different prototype types and represented in different colors

Different prototypes

Different colors are used in UML diagrams to facilitate the understanding of complex UML diagrams

Have their own responsibilities

There may be some commonalities, such as the same properties, operations, and relationships with each other, that should be considered at least at design time

4.2 Collaborative modeling through event storms

4.3 Event Storm Example – Event

As a user, I will be rewarded with 10 points for the check-in task. After I complete the check-in, the system will generate an application for points recharge. After a while, the account balance increased and the application became complete.

| top-up application has accepted | – > | account balance has increased | – > completed | | prepaid phone application

As a user, WHEN I buy a product, I can deduct 1 yuan with 100 points. When I sent the bill of lading, the account balance (100) was locked first, and the integral credit was granted successfully. After the order is submitted successfully, the credit is requested for cancellation, then the account locked balance is converted to deduction, and finally the credit is closed.

| | in the credit application – > | part account balance has been lock | – > | credit | successfully
| in the | credit verification – > | in the | credit verification – > | | credit have cancel after verification

4.4 Event Storm Example – Commands

Cost | member system | – > | | – > | top-up application has accepted | – > | account balance has increased | – > completed | | prepaid phone application
Credit | | trading system | – > | application – > | – > | credit application | part account balance has been lock | – > | credit | successfully
| trading system | – > | verification letter | – > | in the | credit verification – > | account has turned the deduction | – > | | credit have cancel after verification

4.5 Event Storm Example – Aggregate root

4.6 Event Storm example – code

4.7 Event Storm Example – Code

Initiate a recharge request

Increase account balance

Complete the recharge request

5. Aggregate root and data consistency

Application services act as transaction consistency boundaries. No changes to two aggregations can be involved in a single transaction, and data across aggregations should be used for final consistency.

But ultimately consistency costs a lot.

In the previous example, synchronous domain event publishing and subscription was implemented based on memory. In this way, changes to both aggregation roots are actually based on the same local database transaction.

However, because of the event-driven use, updates from the two aggregate roots are decoupled at the code level, making it easy to refactor when final consistency is required.

The green ones need to be added, and the red ones need to be modified. Any code for the business layer (application services and domain models) that has not changed; The transaction message can be sent reliably through event inbox, and the account event table can be prevented from reproducing by the unique constraint of “recharge request ID+ event type”.

6. Application layer and domain layer responsibilities

One way to determine if a set of interactions is domain level is to ask, “Does this always happen?” “Or” Are these steps inseparable?

If so, that sounds like a strategy in domain logic, because these steps always have to happen simultaneously.
If these steps can be combined in a variety of ways, they may not be domain concepts.

7. Field services

When domain logic does not fit in one aggregate, multiple aggregations need to be coordinated, but when domain logic does not fit in the application service, it can be placed in the domain service.
Business logic that requires access to external resources such as databases is not recommended to be aggregated and can be placed in domain services.
Some algorithms and policy code can be distilled into domain services (domain Service classes don’t always end in Service) to keep the responsibilities of entity and value objects simple.

8. Implementation method of resource library

8.1 Principles for Aggregation and Resource Library Aggregation

An aggregation has a repository; other entities do not.

Simplify persistence of aggregation as a whole by “Unit of Work”.

8.2 Implementation method of resource library – JPA/Hibernate

Maintains and tracks the state of objects in memory:

Complexity brought by Hibernate:

Lazyloading and N+1 issues /session closing issues

Many – to – Many mapping

Different FetchModes

• Different FetchModes

We need a simpler ORM that can be tailored to Hibernate features through ArchUnit. For example, forbid aggregation of associations between roots, forbid many-to-many mapping, and forbid Lazyloading.

8.3 Resource Library Implementation mode: Spring-data-JDBC

The website address

Simple and customizable
Native DDD support

8.4 Resource library implementation mode – JDBC/Mybatis

You need to manage the persistence of the aggregation as a whole, such as using the memo mode, recording snapshots, and so on.

9. Out of business logic

CQRS
Combination of the UI
The report

9.1 CQRS – Separation of responsibilities for command query

CQRS:

Command Query Responsibility Segregation

Martinfowler.com/bliki/CQRS….

Question:

In the example in the previous chapter, an Account is an aggregate root, and a recharge record is a child object. If I have a business scenario that queries all recharge records, not one Account recharge record, but all Account recharge records, then:

Does this requirement still use Account as the aggregation root?

If you still use Account as the aggregation root, isn’t it more memory to query the recharge record?

Or a new domain model? Are there too many domain models in this design?

Is the domain model designed for only one scenario

Build the query model in addition to the command model

Increased query flexibility and performance through heterogeneous data

9.2 UI and Reports

Domain Models and Repositories should not be designed for complex queries and reports.

Reports should be based on the data model rather than the domain object model.

One-to-one correspondence leads to experience rigidity:

| UI1 | | UI2 | | UI3 |

Service | 1 | | services | 2 | 3 | services

Experience should cross service boundaries:

| UI1 | | UI2 |