How to implement domain driven design

From Eric Evans wrote the classic Domain-driven design:tackling complexity in the Heart of software to this day, DDD has just developed for 10 years. It is almost the main domain design method of developing complex software system, which is not only the complement of object-oriented (component) design, but also the object Oriented (component) design. Many concepts, such as entity, value object and aggregation, which are put forward in ddd, have become a familiar design term. The development of DDD community is also in full swing, it seems not to be replaced by endless design ideas, on the contrary, it is still developing strongly, absorbing many new concepts and methods, such as functional programming idea, Event Source, CQRS, etc. However, as far as I can see, many projects, though known as DDD design, mostly stay in what Eric calls "tactical design". Even at the tactical level, there are still many programmers who don't understand the difference between an entity and a value object, how to define aggregations and aggregate roots, not to mention the logical context.

I do not understand the true cause of the inside, can only presume to speculate whether DDD appears high? The reason, whether or not Eric caused the misfortune, his classic of the United States is beautiful, but it seems that some do not pick up the atmosphere? At least, that's what my reading feels like. Some other works related to DDD, such as Jimmy Nilsson's book "Field-driven design and model combat", have also been introduced in the country. Although these books are good, they do not fully explain the field-driven design, not to mention the complete practice, until Vaughn Vernon's "Implementation of the field-driven design (implementing Domain-driven)" appears.

The book first attracts me to chapters 2nd through 4th of the book. Although the contents of the book almost faithfully reflect Eric Evans's theory of DDD, the author creatively began by focusing on the strategic design of DDD, including domain, subdomain (subdomain), restricted contexts (unbounded context), Context map and schema. Taking the 4th chapter as an example, this paper makes a deep discussion and analysis of the classical hierarchical architecture of DDD, and proposes that the infrastructure layer (infrastructure Layer) be placed on the user interface layer (users Interface Layer). Originally read, I was surprised, but careful thinking, from the point of view of relying on the inverted principle, it is reasonable. Frankly, it completely solves a problem that has been entangled in my heart before: if we see the entity as repository and the object of the data access, which layer should we put the entity in? In DDD, the entity object undertakes the domain business behavior, but at the same time can generate the mapping through ORM and data table. The data Access objects (that is, traditional DAO) of the infrastructure layer need to invoke these entity objects. If it is at the bottom, it can create a mix of business behavior and infrastructure. Separating the entity from the data mapping object can cause duplication between the objects and lead to bad anemia objects. Putting the infrastructure layer at the top of the layered architecture solves the problem very cleverly.

I particularly like the hexagonal (hexagonal) architecture proposed by Corkburn in this book. It completely broke through the traditional layered structure of the stereotypes, with unique border Division to guide us to follow the principle of separation of concern points. The emphasis of the architecture pattern on port and adapter (Adapter) allows us to focus more on the integration points between systems in architecture analysis and design, resulting in a highly visible physical architecture. This is especially valuable for building scalable, distributed architectures. I have used the hexagonal architecture in the architecture design of several projects, which is quite rewarding. The book also mentions relatively new restful architectures, CQRS architectures, and event-driven architectural patterns and grid distributed computing. The appendix of the book also explores the combination design of aggregate objects and event sources. These elements help us to establish the overall concept of DDD architecture, which can be said to make up for the gaps in Eric's book.

Vaughn Vernon, a technical expert who really knows how to write, knows how to "please" the reader. Open a book, read the first chapter, you will love it, love ddd. The examples given in the book are fantastic. Look at the evolution of his version of the Savecustomer () method, and you'll wake up to the fact that the code should be written like this. The domain object is a cautious confidential person who strictly defends his secret and exposes only the external behavior of the business so that you can read it, but not interfere with its internal implementation. This is the value of universal language in DDD. As a technician, we are proficient in languages such as Java, C #, Scala, Ruby, and so on, but forget that in enterprise development, what really needs to be demonstrated is the business lingua-fide language. Writing code is primarily about communicating with people, not machines.

There are so many wonderful chapters in this book that you can read almost every article. But I personally think that the value of this book is particularly evident in the 8th and 10th chapters. Not all other chapters are good enough, but in contrast to the concepts of entities and value objects, aggregation is often misused or bewildered. The 10th chapter summarizes the very practical principles of aggregation design. For example, the principle of modeling true invariants within a consistent boundary; the principle of designing small aggregations; the principle of referencing other aggregations through a unique identity. The principle of using final consistency beyond boundaries.

As for the domain event in chapter 8th, this is because it differs from Eric's writings and treats the event as a first-class citizen of equal status with the entity. Combining this book with event-driven and event-source explanations, it is believed that you will value the recognition of domain events when modeling in later areas. If we can understand the event correctly, we can better master the CQRS mode and use it to the local conditions.

The book's title is Implementing (Domain-driven) design, which shows that the author's intention is to let DDD really landed. How do you do that? --On the example! Although the book gives a virtual case, but very close to the real. The author has even introduced these two complete cases in an evolutionary design way. The most helpful thing to understand is that when he teaches DDD, he also combines the case to give a bad case before, and uses the DDD method to improve it by identifying the poor taste of the design. The author even created a virtual scene, so that when we read these content, as if we really participate in the discussion of the designers, and even hear their arguments, and finally a DDD expert's summary, really like to join the virtual team, learn together, share, and grow together.

Frankly speaking, I have found myself in the shallow ignorance of ddd when I read this book. Maybe it's not enough to understand Eric's concept of DDD. Reading this book gives me a sense of the senses. Now, for DDD, I've been getting a glimpse of the gateway. If you can combine project practice, you will be able to go in and even farther.