Go to. NET Architecture Design-Chapter 4-business layer layered architecture (Part 2)

To. NETArchitecture Design-Chapter 4-Business Layer layered architecture (Part 1)

In the previous article, we discussed two business logic models: Transaction Script and Active Record. This article describes the Domain Model and Anemic Model.

Note: No matter how difficult the technology is, we still have to implement the technology in a down-to-earth manner. I also hope that my friends will continue to support this series.

 

This topic is as follows:

Transaction Scrip (Previous)

Active RecordPrevious)

Domain Model(Part 1)

Anemic Model(Part II)

DDD(Part II)

 

 

Domain Model:

During the development process, we often use Domain Model to Model the target business Domain. The business class modeled by Domain Model represents some concepts in the target Domain. In addition, we can see that some objects modeled by Domain Model simulate data in business activities, and some objects also reflect some business rules.

 

Let's take a look at the development of e-commerce systems. In the development process, we have created some conceptual models to reflect some concepts in the e-commerce field: shopping cart, orders, order items, etc. These models have their own data and behaviors. For example, an order model contains not only some attributes (sequential number, creation date, and status), but also some business logic: users who place orders are legal, whether the account balance is sufficient.

 

In general, the deeper we know about the field, the closer the model we establish in the software to the concept in reality, the more software we implement to meet the customer's needs. At the same time, we also need to consider the implementation of the model in the modeling process. Maybe we have made a good modeling of the domain and met some concepts of the target domain, however, it is very difficult to implement the software, so we have to weigh the balance: to find a better mode, it is also easy to implement.

 

In previous articles, we mentioned some Domain Model things. In fact, the difference between Domain Model and Active Record is that Domain Model doesn't know how to persist its data, PI (Persistence Ignorance ). that is to say, the business classes created through Domain Model are all POCO (Plain Old Common Runtime Object ).

 

Create a new solution named ASPPatterns. Chap4.DomainModel and add the following project:

 

 

 

 

Let's take a look at the meaning of each project representative:

Where:

Q AgileSharp. Chapter4.DomainModel. Model: business layer. This class library project contains all the business logic and Business Objects in the system, as well as the relationship between business objects. This project also defines interfaces for objects in the persistence field and is implemented in the Repository mode (Repository mode will be discussed later ). This Model layer does not reference other class library projects and focuses entirely on the business.

Q AgileSharp. Chapter4.DomainModel. Repository: this Repository class library project implements the persistent interface defined in the Model class library. Repository references the Model class library project.

Q AgileSharp. Chapter4.DomainModel. Infrastructure: Provides auxiliary functions, such as sending emails and logging.

Q AgileSharp. Chapter4.DomainModel. Contact: contains the data contract and service contract.

Q AgileSharp. Chapter4.DomainModel. Service: implements the Service interface provided by the Contract layer and exposes the Service to the outside world through the Web Service interface.

Q AgileSharp. Chapter4.DomainModel. WCFHost: the WCF Host Program.

Q AgileSharp. Chapter4.DomainModel. WPFUI: mainly responsible for the final display logic and implementation of some user experience. This class library calls the APIS provided by the service layer to submit requests and display results.

 

Most of the time, you can design a data model (such as a data table) based on the business model, then adopt appropriate policies and follow certain rules, to ensure efficient access to data (topics related to data models and domain models, in chapter 1 of this book, "Domain Models. the logical model section will be detailed ). Here, the domain model is relatively simple. The structure of the corresponding data model is basically the same as that of the domain model. However, in many systems, the domain model and data model are different. For example, the data of a business model comes from multiple data models.

 

The following describes how to create an Order domain class:

 

Public class Order
{
Public string OrderNo {get; set ;}
Public OrderStatus Status {get; set ;}
Public List <OrderItem> Items {get; set ;}

// Calculate the total order price
Public decimal CaculateTotalPrice ()
{
Decimal result = 0;
If (this. Items! = Null & this. Items. Count> 0)
{
Result = this. Items. Sum (u => u. Products. Sum (p => p. Price ));
}
Return result;
}
// Check the order status and determine whether the order has been processed
Public bool CheckStatus ()
{
Return this. Status! = OrderStatus. Processed;
}
}

Public enum OrderStatus
{
New,
Processed
}
}

As mentioned earlier: each business class only focuses on its own business, and each process is composed of multiple business classes and other auxiliary classes. In many cases, the service class is added to the domain layer, form a "thin" service layer (also called the application layer ). Next we will discuss the topic about the service layer (chapter 1 of this book will discuss the service layer in depth ).

A common method for processing domain logic is to divide the domain layer (also known as the "Business Layer") into two layers: the service class is independent from the domain layer and serves as the service layer.

 

The implementation of data access here is relatively simple, mainly through implementing the IOrderRepository and IProductRepository interfaces using Linq To SQL. The Code is as follows, and will not be described here:

 

Public interface IOrderRepository
{
Bool Save (Order order );
}

Public interface IProductRepository
{
Product GetProductByName (string productName );
}

 

The last step is to process the display layer.

In this example, the display layer uses the traditional ASP. NET, and the simplest implementation is used. If needed, you can adopt the MVP mode. This is another article in my article (going forward. NET Architecture Design-Chapter 3-layered design, detailed description in the initial architecture (Part 2). I hope you will not repeat it here.

 

At this point, the Domain Model is basically finished. We can see that when the business in the software is more responsible, we may use Domain Model better. When we use Domain Model, we focus all our energy on modeling the business field, abstracting the business concepts, and turning them into models that can be implemented by software. In fact, it is not so easy to abstract the business model. It is usually necessary to make a more in-depth analysis of the field.

 

At the same time, there must be a balance between business modeling and implementation. Sometimes, we thoroughly analyze the business, but the concept of analysis cannot be converted into implementation, resulting in "no fish if the water is clear ". I hope you will learn more about the differences between business logic models of several organizations.

 

Today we are here. I hope you will forgive me and support me! Thank you!