Application Framework Combat 13: My opinion on the DDD layered architecture

An important part of the application framework-the common operations class-is described earlier, and a data type conversion public action class is provided as an example for demonstration. Here's another important part of the application framework, architecture support. You don't have to use a structure like DDD, you can use a single-tier architecture like an ordinary three-tier architecture, but if you want to get further reusability and encapsulation, using more object-oriented techniques is a must.

I was still using the old ASP. NET WebForm and the original ADO before 2010. I had an idea before:. NET technology development too fast, followed by Microsoft behind the buttocks run too tired, so only use it some raw things, their own package can also meet the needs of the work. For a technology like LINQ it was just a casual look, especially when a lot of people told me that LINQ was dead, never to learn, and I liked that kind of talk because there was a good reason not to learn new knowledge.

By the year 2010, I once went to the blog park, browsing a number of articles, found full of various abbreviations and nouns, what dtos, work unit class, I know the next generation. NET technology has begun to spread, I have already out. Then I started to learn EF and MVC, and when I first approached EF, I learned from some blogs that in order to play the power of EF, I had to design with DDD. In order to clear the way, I bought a few DDD books to learn, learning process only to find that object-oriented and agile development is the key, so began to buy a large number of books, out of the way, four years time bought nearly 200, finally the foundation to fill up a little.

The core idea of DDD is to describe how to model the business domain using an object-oriented approach, and how to get a better domain models. Although read a lot of DDD information, but still feel it is unusually abstract, but also the object-oriented thought is difficult to progress, and may be related to the previous years of programming habits, has been accustomed to from the perspective of data, the formation of a mindset.

Although DDD is abstract, it provides some technical support. Most people start with a DDD hierarchy to learn and practice, of course, DDD is not a layered architecture, but a layered architecture is just a technical construct of DDD. Here is a brief introduction of my understanding of the DDD layered architecture, because I use DDD for a short time, I described the views are some of my own development experience, not necessarily correct, welcome you master criticism, common progress.

The DDD layered architecture is similar to the three-tier architecture in general, but more specific responsibilities and building blocks are proposed for each layer. I also often communicate with friends who are using the DDD hierarchy, and I ask them what the difference between a DDD tiered architecture and an ordinary three-tier architecture, most people feel like, except for some terminology. If you are feeling the same way, then maybe this article is helpful to you because I clearly feel that they are different.

The DDD layered architecture and the traditional three-tier architecture are as follows.

(Domain driven design tiered architecture)

(Traditional three-tier architecture)

The most important difference between a ddd layered architecture and a traditional three-tier architecture may be a different center of gravity, i.e. the focus of the traditional three-tier architecture is on the business logic layer, while the DDD layered architecture focuses on the domain layer.

The core of object-oriented design is based on business concept modeling and mapping into code, and the benefit is that it eases the burden of programmers translating business concepts into technology because it is easier to understand. Although the traditional three-tier architecture also transforms the business concept into a model object at the physical layer, the physical layer is just an ancillary facility, which is not a significant part of the container used to load data. The DDD layered architecture refers to the domain layer as a key place for business logic.

The first benefit of using a DDD layered architecture is that the business logic is highly cohesive to the domain layer, in other words, if there is a logical problem, the domain layer is right. For this, some people think that the traditional three-tier architecture can also be found in the business logic layer is not the same? This is probably the key to the understanding that the domain-driven design hierarchy cannot break through.

While you can write all of your business logic to the BLL layer as required by the tiered architecture, you can't pinpoint exactly where the business logic you need is, in other words, a unique point of access to your business logic. Since you cannot easily find the access point of the business logic, it is inevitable that redundant code will be generated in multiple places, resulting in a reduction in maintainability. Some problems can be mitigated by forcing constraints on code and directory specifications, and by extracting public methods, but to solve them fundamentally, you have to ask for help for the object.

So, where is the best foothold for business logic, the most intuitive, the most easily thought of the only access point where? For example, you have to deal with an order, so that you go to other places to find the code to deal with the order, you naturally difficult to find. So if the code is inside the order entity, the situation is quite different, and you can find it in the shortest possible time. By clustering business logic within a domain entity, you can create a unique access point for your business logic. When you need some logic in the future, let's see if there's anything in the entity you need, so you can significantly reduce code redundancy to better maintain.

So my first DDD Experience was to use the congestion model to put business logic into domain entities as much as possible . The congestion model has a lot of controversy, but you can not ignore the other people's argument, their practice can be a real truth. The use is not good, you do not have to be behind, to you basically have no influence. At the moment, I'm using the congestion model, and I feel that the main problem is that if you use a distributed architecture, such as using WCF remote calls in the middle, you need to transfer through a dedicated DTO, and you need to add a remote-looking service, which can cause an increase in workload.

When the congestion model is used, the next step is to use the aggregation. The concept of aggregation is well understood, which is the inclusion of relationships. In UML there are two kinds of inclusion relationships, the first one called aggregation, which represents a weaker containment relationship, and what is inside the aggregation can be accessed directly outside. The second is called the combination, that is, the composition of the aggregation, is a strong inclusion relationship, the outer object is composed of multiple sub-objects inside, internal sub-objects outside the direct access, must be indirectly referenced by external objects. Although DDD uses the word aggregation, it represents the aggregation of components in UML, so it refers to an external object as the root, the aggregate root, and to access the internal object, the aggregate root must be accessed first.

The concept of understanding, in addition to blowing bragging, not much help. When I first approached DDD, I could understand the concept of aggregation, saying that it was the same as the foaming, but it really took almost a year. In addition to my slow response, there is another reason to be constrained by the previously data-centric mindset.

I also often download some DDD demo to learn, but these examples are mostly very simple, so I mainly rely on reading and my own groping. My first usage is that a table corresponds to a domain entity, and each domain entity corresponds to a warehouse. I was in the process of using, faint found what is wrong, but can not find out the specific reasons. After more than half a year, I also used DDD to develop a few simple projects, gradually accumulated some experience, in a reading, I suddenly realized that my DDD usage main problem is the dependence of confusion, and the means to solve these dependencies is aggregation.

The primary impact of aggregation is to significantly reduce the number of warehouses and to centralize the management of related entities that are highly dependent. By aggregating highly relevant entities into a single aggregation, these dependencies can be encapsulated in a smaller space, with the external only interacting with the aggregate root, and the dependency on the aggregated inner sub-objects is significantly reduced. An aggregation corresponds to a warehouse, not an entity object a warehousing can reduce the number of warehouses and thus further reduce the dependency relationship.

After I re-read some of the blog and books, found that others have actually said clearly, but I did not understand it at the time, it is really a paper on the end of the preach to know this matter.

my second ddd. The use of experience is to encapsulate highly relevant entities into aggregations and create a warehouse for each aggregate root.

Observing the above-mentioned DDD hierarchy, it is found that the domain layer relies only on the application framework service, the warehousing uses the interface separation mode to separate the implementation and the interface into different assemblies, the domain layer contains only the warehousing interface, this design makes the domain layer very pure, and the external dependencies to a minimum. What does this mean for us? The lower dependency allows us to easily unit test the business logic, especially with TDD, which is especially important. We can use simulation frameworks to test storage and external dependencies in unit tests to dramatically improve the stability and robustness of business logic.

In addition, observing the traditional three-tier architecture, the business logic layer is generally directly dependent on the data access layer, making unit testing difficult and moving to more coarse-grained integration testing.

Through the above analysis, we can see that the DDD layered architecture can achieve better reusability, maintainability, testability and so on than the traditional three-tier architecture.

Of course, it is not possible to put all the business logic in the domain entity, some functions need to operate multiple entities, or need to use some design patterns, this time need to use Domain Services. The point here is to delegate the operation of the domain service to the domain entity as much as possible, because the business logic can be more centralized.

The DDD hierarchy also has some building blocks that I'll cover in detail later in the article. If not introduced, I am still in the study and groping stage, there is not much experience, and so I have some experiences to tell you later.

Now to summarize.

　　What are the benefits of using a DDD tiered architecture

• Helps you to manage your business logic more centrally.
• Help you reduce the dependencies between the tiers and the business modules.
• To help you do unit testing more easily.

　　My DDD tiered Architecture usage experience

• Using the congestion model, the business logic is placed as far as possible into the domain entity, and the domain entity provides a unique access point for the business logic.
• Can not be put into the domain entity logic, as far as possible to the domain Services, in short, the business logic should be highly cohesive to the domain layer.
• Encapsulate highly relevant entities into aggregations and create a warehouse for each aggregate root.

Finally, let's remind you that we use some ddd layered architecture to construct blocks, probably not really used ddd. But is our goal to use DDD? No, our goal is to make business logic more stable and better maintained. So do not care about their use of technology is not authentic, standard, as long as better than before, it should persist.

Http://www.cnblogs.com/xiadao521/p/4098100.html

Application Framework Combat 13: My view on the DDD layered architecture (GO)