My view of domain-driven (DDD) based on Golang implementation

Share a little immature understanding, but also in the exchange of the great principles of progress to spray. It has been more than 1 years since I started to touch and apply DDD last year. has also led the application in 2 production projects, all based on. Net core, fully referencing the Https://github.com/EduardoPires/EquinoxProject framework of the project.

First, some concepts

DDD Classic Layering:

One important principle of layered architecture is that each layer can only be coupled to the layer below it. Strictly layered architecture, where a layer can only be coupled with a layer directly below it, loosely layered architecture allows any upper layer to be coupled to any underlying layer. Big principle so, I generally use loose stratification, strict too exaggerated, in the team promotion is very difficult.

CQRS:

Command query separation of duties is proposed by Betrand Meyer (father of Eiffel Language, OCP). Command: no result (void) is returned, but the state of the object is changed. Query: Returns the result but does not change the state of the object and has no side effects on the system. In the course of my practice, I actually let the command return some primary keys and the like.

Es event Traceability:

In CQRS, each determined command operation, whether successful or unsuccessful, generates a corresponding event after execution. This only needs to record the event that all the system is running and the data that it produces, this is the history of the system, and it can be easily rolled back to a historical state. The event Sourcing is used to store and manage events.

After a cursory knowledge of these concepts, it is basically possible to understand and build the most basic domain-driven architecture.

Ii. General Practice

The overall hierarchy is as follows:

1.presentation presentation layer. The web framework chose Beego,beego based on MVC. I put the V and C layers on the presentation layer. Routing settings, views, and controllers these are all layers of expression. Domain-driven design, more focused on the business, and its changes can be relatively good extension and maintenance. The expression layer logic is also very simple, mainly to undertake the Beego framework forward request, and then through the Memorybus will request to publish out, as to who subscribed to the request, unified entrusted to the third party httpserver to deal with, this is the essence of Dimitri Law. A direct association (coupling) between a presentation layer or a Web request with a specific business service that handles the request is lifted. The advantage of doing so is to cite only one example. The business layer can be a standalone distributed service, not necessarily with the presentation layer in a process service.

　

2.application application layer. The application layer in DDD is a very thin layer, only as the transition layer of the computer domain to the business domain. For example, the computer can identify and transmit the 2-byte stream, which can act as a translator, translating these obscure machine "languages" into the language that the domain's business people have modeled. Or a high-level computer programming language, there is usually a special viewmode to take the required parameter data. This layer directly consumes the domain layer, and begins to record some system-based functions, such as logs, event traceability.

3. domain Domain layer. Domain-driven design is the most central part, can be broken down into the aggregation of roots, entities, domain Services, such as a lot of other concepts. Here is no detailed explanation, simply understand the aggregation root, responsible for all the functions of the aggregation business is all right. Here is an example of the Protocol protocol, which is directly responsible for all the business related to the Protocol, internal encapsulation, complete all the required functions, from the aggregation root to provide a unified method of the external.

4. Infrastructure infrastructure layer. This layer typically abstracts out all the public functions, as an independent export of some helper classes. But I'm just focusing on the warehousing function, which is the function of dealing with the database. This layer is also focused on business logic, and only focuses on providing common functionality.

5.crossutting, Ddd_interfaces, Dddcore, these are not in the DDD classic hierarchy, is mainly used to facilitate the implementation of DDD, the addition and separation of some of the interface, and the basic concept implementation.

Third , a little sentiment

The understanding and application of DDD is still very immature, just a summary of the past. Golang is also a novice, just read the "Go Language Bible" and the use of Astaxie Golang to build Web apps.

It is true that go's object-oriented design does not inherit, but uses a combination of methods to achieve "inheritance" in Oo. As much as possible using combinations rather than inheritance, but also a principle of object-oriented design, Golang natural directly followed. "Encapsulation" is also very interesting, directly through the first letter is the case, "polymorphic" has not yet understood thoroughly can not be described. When using Golang to realize DDD, it is also found that if there is a "generic" on the feeling of good. This time more profound understanding and experience, the benefits of generics. Have to admire the designers of C #, very early has a generic type.

The simple construction of a DDD implementation, immature place there are many, but the iteration is a good thing, slowly understand and perfect.

Code Address: Https://github.com/KendoCross/kendoDDD