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

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

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

Today's content is relatively simple, and it is also the end of this chapter!

 

This topic is as follows:

Transaction Scrip (Previous)

Active RecordPrevious)

Domain Model(Part 1)

Anemic Model(Part II)

DDD(Part II)

 

　

　 

Anemic Domain Model:

At first glance, the anemia Domain Model is very similar to the Domain Model. However, they are indeed different: Domain Model Domain classes contain their own business logic and data, as well as the relationship between objects; the Domain class of the Anemic Domain Model transfers all of its own business processing logic out of the Model-there is a dedicated Business Rule class, which makes the Domain Class A simple data object.

The disadvantage of this mode is that the Code in the domain service class is more structured, which is similar to the Transaction Script mode, which brings about the same problems as the Transaction Script Mode. For example, one of them is against the "Tell, Don't Ask" principle: Business Objects should have told the Customer Code whether they can perform an operation, instead of letting the Customer Code determine whether the execution should be performed based on the state of the business object, the business class is no longer "autonomous" because all logic has been removed from the business class.

If the Anemic Domain Model is used to implement the previous Order processing example, the Order Service Code is as follows:

 

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

 

The Order business rules are placed in a specific rule class, as shown below:

 

Public class PorcessStatusSpecification
{
Public bool IsSatisfiedBy (Order order)
{
Return order. Status! = OrderStatus. Processed;
}
}

 

Currently, the OrderService domain service method is as follows:

 

 

Public bool OrderProcess (Order requestOrder)
{
Bool result = false;
Var order = requestOrder;
ProductService productService = null;

If (order! = Null)
{
PorcessStatusSpecification specification = new PorcessStatusSpecification ();
If (specification. IsSatisfiedBy (order ))
{
ProductService = new ProductService ();
Var hasInventory = productService. CheckInventory (order );
If (hasInventory)
{
Order. Status = OrderStatus. Processed;
//...
}
}
}

Return result;
}

 

The code above shows that OrderService completely replaces the original Order and changes the status of Order. As the complexity of the logic increases, many auxiliary methods will appear in the service class, which will make the service class end unable to be maintained like the Transaction Script.

So far, the four business logic models of the Organization have been described. Each of them has its own purpose. It doesn't matter whether it is "used or not used ". Which one is used depends on the project and experience.

 

DDD:

Next we will go to DDD. Here we will only talk about some basic concepts in DDD, as for DDD:

1. Subsequent chapters will be introduced one after another

2. Read "Domain-driven design. How to Deal with software core complexity". If you need it, leave your Email and I will send it to you.

Some of the following texts are excerpted from some books. The goal is to give you a quick idea of DDD..

DDD concepts:

Layered Architecture

Entity

Value Object

Service

Module

Aggregation

Factory

 

 

Layered Architecture

 

When we create a software application, a large part of the application cannot be directly associated with the domain, but they are part of the infrastructure or serve the software. It is better to make the domain part of the application less mixed with other parts as much as possible, because a typical application contains a lot of code related to database access, file or network access, and user interface.

 

In an object-oriented program, user interfaces, databases, and other supporting code are often directly written to business objects. The additional business logic is embedded into the UI components and database scripts. The reason for doing so is that it is easy to make things work quickly.

 

However, when domain-related code is mixed into other layers, it is extremely difficult to read and think about it. On the surface, it seems that the changes to the UI are actually changes to the business logic. Changes to business rules may require careful tracking of user interface-Layer Code, database code, and other program elements. The implementation is stuck together, and the model-driven object becomes no longer feasible. It is also difficult to use automated testing. For the technology and logic involved in each activity, the program must be kept simple, otherwise it will become difficult to understand. Therefore, a complex program is split into layers. Develop the cohesion design in each layer so that each layer only depends on the layer under it. Complies with standard architecture models to provide low coupling of layers. The Code related to the domain model is centralized into a layer, which is separated from the user interface, application, and infrastructure code. Release the domain object's responsibilities, such as displaying itself, saving yourself, and managing application tasks, so that it can focus on displaying Domain Models. This will further enrich a model with knowledge, clearly capture basic business knowledge, and let them work normally.

 

A generic domain-driven design's disruptive solution includes four conceptual layers:

 

It is important to divide applications into separate layers and establish inter-layer switching rules. If the code is not clearly isolated from a layer, it will be immediately confusing because it becomes very difficult to manage changes. A simple modification to the code somewhere else will cause immeasurable results to the Code elsewhere. The domain layer should focus on core domain issues. It should not involve basic category activities. The user interface is neither closely bound with the business logic nor contains tasks typically at the infrastructure layer. In many cases, the application layer is necessary. It becomes a manager based on the business logic and is used to supervise and coordinate the entire application activity.

 

 

For example, for a typical structured application, the domain and infrastructure layers look like this: the user wants to book a flight route and needs to use an application service at the application layer. Applications obtain relevant domain objects from the infrastructure in sequence and call their related methods, such as checking the security boundary with another flight line that has been scheduled. After the domain objects perform all the checks and modify their statuses, the Application Server

Objects are persistently stored in the infrastructure. 

 

　Entity

An object may seem to have an identifier. Its identifier remains consistent after various states of the software. For these objects, this is no longer an attribute of interest to them, which means that a series of continuity and identifiers that can span the lifecycle of the system or even surpass the software system. We call this object an object.

 

The OOP language puts the object instances in the memory, and they maintain a pair reference or record an object address for each object. At a given moment, such a reference is unique for each object, but it is difficult to ensure that it is the same in an uncertain period of time. In fact, the opposite is true. Objects are often removed or moved back to the memory. They are serialized and transmitted over the network, and then re-established at the other end, or they are all eliminated. In the running environment of a program, the reference relationship that looks like an identifier is not actually the identifier we are talking about.

 

If there is a class that stores weather information (such as temperature), it is easy to generate different instances of the same class. Both instances contain the same value, these two objects are completely equivalent and can be exchanged with one another, but they have different references and they are not entities. If we use a software program to implement a "Person" concept, we may create a Person class with a series of attributes, such as name, date of birth, and place of birth. Which of these attributes can be used as the Person identifier? A name cannot be used as an identifier because many people may have the same name. If we only

Considering the names of two people, we cannot use the same name to distinguish them from each other. We cannot use the date of birth as an identifier because many people are born on the same day. Likewise, Place of birth cannot be used as an identifier. An object must be distinguished from other objects, even if they have the same attributes. Incorrect identifiers may cause data confusion.

 

Consider the next banking accounting system. Each account has its own digital code. Each account can use its digital code for exact identification. This digital code remains unchanged throughout the lifecycle of the system and ensures continuity. The account code can exist as an object in the memory or be destroyed in the memory and sent to the database. When this account is closed, it can also be archived. If someone else is interested in it, it will still exist somewhere. Regardless of the format, the number code remains consistent. Therefore, implementing the real body in the software means creating an identifier. For a person, its identifier may be a combination of attributes: name, date of birth, place of birth, parent name, current address. In the United States, social insurance numbers are also used to create identifiers. For a bank account, the account seems to be enough as an identifier. Common identifier or pair

An attribute (or a combination of attributes), an attribute created specifically for saving and expressing the identifier, or an action. For two objects with different identifiers, it is very important that they can be easily distinguished by the system, or that two objects with the same identifiers can be seen as the same by the system. If this condition cannot be met, the entire system may be faulty.

 

There are many different ways to create a unique identifier for each object: an ID may be generated automatically by a model and used internally in the software, so it will not be visible to users; it may be a primary key of a database table and is guaranteed to be unique in the database. As long as the object is retrieved from the database, its ID will be retrieved and re-created in the memory. The ID may also be created by the user. For example, each airport will have an associated generation

. Each airport has a unique string ID that is universal worldwide and used by every travel agent in the world to identify the airports involved in their travel plans. Another solution is to use an object property to create an identifier. When this property is insufficient to represent an identifier, another property will be added to help identify each object.

 

When an object can be partitioned by its identifier rather than its attributes, it can be used as the primary definition in the model. Ensure that the class definition is concise and focus on the continuity and identifiability of the life cycle. Define a meaningful distinction for each object regardless of its form or history. Be cautious about the need to use attributes to match objects. Define an operation that ensures a unique result for each object. This process may require a symbol to ensure uniqueness. This means that the identifier can come from the outside, or it can be generated by the system and use any identifier, but it must conform to the identity differences in the model. The model must define which are considered the same thing.

Entities are very important objects in domain models, and they should be considered at the beginning of the modeling process. It is also important to determine whether an object needs to become an object. This will be discussed in the next model.

　　 

Due to the length of the article, there is not much to write here. You can download the DDD Lite version first. If you need it, leave an Email. I will give the full version of DDD!

 

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