Layer-3 architecture is not enough-layer-3 architecture in the DDD eye (with C # source code implementation)

The root of software complexity comes from the complexity of thinking.

Three-tier architecture look at three-tier DDD Implementation detailed architecture look at Code Business Domain persistent layer (data layer) testing and use example complete code download

 

 

Handy weapon Library:

• Fluent nhib.pdf

• Nunit

• Git (GitHub)
  

 For the tools involved in this article, see the previous article: My. Net weapons library ------ list of required tools for the new. Net Architecture

L3 Architecture

Compared with the new concept that is changing with each other, the three-tier architecture has become old. Although there are still disputes, there is more consensus in the industry.

Figure 1 Description of common Three Layers

 

It is simple and clear enough. I still want to remind you that the arrows connecting layers are very important. The arrows refer to the definition of UML to indicate dependency. That is to say, you must first have a data layer before the business layer and then the performance layer. This is a small problem. No, this is a big headache!

View Layer 3 from ddd

For the time being, let's take a look at this topic and pick something new. Business Domain-driven development (DDD) has been booming in recent years. However, what it is and what it is, it seems that it is not as well known as a three-tier architecture.

Figure 2 three-tier architecture from the perspective of DDD

 

The core of the system is the business domain. All other content irrelevant to the business is external services/functions. As described in this article, two special external functions, persistence layer and user interface are provided independently.

Which of the two seemingly completely different architecture designs is better? Each of them has a large number of advocates, a large number of discussions, and three of them seem to be completely different. At least the articles we often see give us such an impression. Naturally, why cannot we integrate our thinking? In fact, they are not as big as they seem to be. In terms of terms, although I intentionally staggered the names, we can still see the corresponding relationship between them, business layer = business domain, data layer = persistent layer, and performance Layer = user interface. Of course, the differences in terms of these details are still necessary. After all, they are not exactly the same thing.

Detailed architecture of the three-tier implementation of DDD

Well, the abstract discussion is enough and we are confused. The details are king. How can we achieve this? Let's take a look at the simplified architecture diagram of this actual system ..

Figure 3 Actual Architecture Design

 

As you can see, when the three layers are kept clear, it is important to change the dependency. The so-called dependency injection (DI) is only a practical technical implementation to fulfill and implement this architectural design requirement. We can also clearly see that the figure is centered on domain. Of course, this is simplified and not complicated at the beginning.

View code

Finally, let's take a look at the specific code to have a better experience.

Domain examination class:

A simple examination class shows that the class definition in the domain is almost unaffected by the persistent layer (database), except for two points:

1. the attribute ID comes from the primary key of the data table;

2. If you want to use the lazy load of nhib.pdf, each attribute must be virtual.

Even so, this class is clean enough. I also see that some system implementations specifically define a basic class entity, and then put the ID definition in this class. I don't think it is necessary.

As an example, this domain class is very simple, but it is the core. The more the project grows, the more powerful this layer is. The following sections seem complicated. In the future, there will be no major changes, but it will become more and more simple.

Warehousing interface:

Note:

1. The interface name. I didn't add I. This is special.

2. the query <> interface is used to abstract the query. The advantage is that you do not need to create a warehouse interface for each class like most warehousing implementations, which is very inflated.

The quer interface is very simple. There are no methods or attributes, just to use a strong type. Its implementation classes will increase as needed. Because query is almost the main function of the data layer.

Query interface definition:

Persistent layer (data layer) Exam ing class:

Fluent nhib.pdf:

Fluent nhib.pdf Configuration:

The SQLite text database used as an example.

Test and use example to automatically create a database:

Here, the function is implemented in the form of a test. If you run this test, the database is automatically generated. In addition, the script generated by the database can be displayed. In the product environment, I use this script for database installation.

Operation data (simulated UI ):

Similarly, the UI data operations are simulated in the form of tests.
First, run create_a_exam () to insert an exam object.
Then, run get_the_exam_by_id () to obtain the just-inserted exam.
Run delete_the_exam () to delete the exam.

(The copyright in this article is 2012-2013 Yu qin'an. | Reprinted with the author and source wanghaoblog.com)

Full code download

• Download Page
• Direct download