poto-framework
- Process-oriented to Object Oriented Programming, or POTO, welcome to Github Star
- Github.com/bfxyzshb/po…
The status quo
- Now microservices are very popular, and it is said that the architecture is based on the macro design of the business, while ignoring the architecture at the code level, so most of the projects are well divided by microservices.
When opening the actual code of each micro-service, some can be said to be almost unmaintainable. The code is based on Restful MVC code structure level, and even the module division is MVC (simple project can still be used). Once the project is complex, the accumulated business code accumulation, All kinds of technical personnel at random to write code, code miserable!! I believe that the biggest headache is looking at other people’s code.
- Writing process-oriented code in an object-oriented language.
DDD domain driver
- DDD is not a set of architecture, but an architectural idea. Poto-framework is only a constraint on the framework, lowering the threshold of DDD practice. The business layer domain is the key.
DDD four-tier architecture
- Evans recommends a layered architecture for domain-driven design in his book Domain-Driven Design: Solutions to Software Core Complexity:
In fact, we are familiar with this kind of layered architecture for a long time. MVC pattern is a kind of layered architecture that we are familiar with. We try to design each layer as much as possible to keep it highly cohesive and only rely on the lower layer, which reflects the idea of high cohesion and low coupling. The user interface layer can be understood as the Controller of the Web layer. The application layer has nothing to do with business and is responsible for coordinating the work of the domain layer. The domain layer is the business core of the domain driven design, including domain model and domain service. Regardless of display and storage issues, the base implementation layer is the lowest layer and provides the basic interface and implementation. The domain layer and application service layer implement functions such as persistence and sending messages through the interface provided by the base implementation layer.
- Improved DDD layered architecture and DIP dependency inversion principle
As you can see from the figure, the base implementation layer sits on top of all the other layers, and the interfaces are defined in the other layers, which the base implementation implements. The definition of the dependency principle can be restated in DDD design as: other layers, such as the domain layer, should not depend on the underlying implementation layer, but both should depend on abstractions, and when concrete is implemented, these abstract interface definitions are placed in the layer below, such as the domain layer. This means an important landing guideline: all abstract interfaces that depend on the implementation of the base should be defined at the domain or application layer.
What are the benefits of adopting the dependency inversion principle to improve the DDD hierarchy beyond the DIP benefits described above? In fact, this layered structure is more cohesive and less coupled. Each layer depends only on abstraction, because the concrete implementation is in the underlying implementation layer and does not need to be concerned. As long as the abstraction remains the same, there is no need to change that layer, and the implementation only needs to change the underlying implementation layer if it needs to.
Java design principles
- Single responsibility principle
- Dependency inversion principle
- The open closed principle
What is CQRS?
CQRS architecture stands for Command Query Responsibility Segregation and event driven. The noun itself was probably first proposed by Greg Young, but the concept has been around for a long time. In essence, CQRS is also a read-write separation mechanism, which is a simple and clear design pattern. The architecture diagram is as follows:
CQRS divides the whole system into two parts:
- Command Side Write Side
All Insert, Update, and Delete commands are received and converted to commands. Each Command modifies the status of an Aggregate. Commands on the Command Side usually do not need to return data. Note: This “write” operation may involve a “read” operation, which can be performed directly on this Side rather than on the Query Side for validation purposes.
- Query Side The read Side
Accept all query requests and return data directly.
Why CQRS
- Domain plays a core role in DDD. DDD implements business logic and processes through the interaction between domain objects, and separates business logic in a hierarchical manner for separate maintenance to control the complexity of the business itself. But as a business system, [query] related functions are also indispensable. In the implementation of a variety of query functions, it is often found that it is difficult to use the domain model to achieve the query is more direct query data object(DO) can be completed, using the domain object but increased the complexity.
Implementation of DDD and CQRS architectures
- In the architecture, we treat external services such as Web, RPC, DB and MQ equally, and the base implementation depends on the abstraction inside the circle
- When a Command request comes in, it coordinates the domain layer work through the CommandService of the application layer, and when a Query request comes in, it directly interacts with the database or external services through the implementation of the underlying implementation. All of our abstractions are defined inside the circle, and the implementation is in the infrastructure.
How to use
- Github.com/bfxyzshb/sa…
The document
- Github.com/bfxyzshb/po…