Business Controller Design Mode in OEA

For organizations with business logic, I personally think it is best to use the domain driven design method. Ddd uses Domain Models to express the relationship between entities, and uses services at the application layer to organize the process between entities.Code. Both constitute the entire applicationProgram(Pattern of enterprise application architecture).

 

OEA is a framework based on DDD ideas. In OEA, service and controller are used to organize procedural logic. The structure is as follows:

For large systems, the service in OEA is mainly used as the facade interface for distributed calling and local calling, and the main business process is written by controller. For small systems, you can directly write the business process logic in the service.

 

When designing the controller, pay special attention to the following two points:
* Scaling point: a procedural method in the Controller that expresses Business Process behavior and can be extended. This extension should not change the caller's code.
* Unidirectional dependency: one-way dependency between controllers. Otherwise, the business logic will be disordered.

 

I use the class diagram of a recently compiled warehouse management product to describe how to design it and better achieve the above two points:

The business logic of this warehouse management product is organized by the Controller. After writing the product, you can write the Extension Assembly to compile the extension for the business logic in the product trunk assembly.
Client : The client program in the main assembly, which calls the service to complete the distributed call logic.
Service : The service program in the main assembly, which calls the factory to create receivecontroller to indirectly complete the warehouse receiving logic.
Receivecontroller : The warehouse receiving service controller in the main assembly. It organizes the warehouse receiving-related domain models (such as warehouses and goods) to complete related services.
Receivecontrollerext : The inbound business controller in the extended assembly. It inherits the receivecontroller in the autonomous assembly and overwrites the receive method in the base to provide new business logic for receiving data.
Movecontroller : The database migration service controller in the main assembly. It depends on the warehouse receiving controller. After the goods arrive in the warehouse receiving service controller, it needs to execute the specified database migration logic. The warehouse receiving controller cannot rely on the database migration controller. In this way, the database migration controller can be removed in some scenarios to achieve simple warehouse receiving without executing the database migration logic.
OEA. Controller : The controller base class provided by the framework, "layer base class mode ".
OEA. controllerfactory : The Controller factory provided by the framework. The factory model encapsulates the construction process of all business controllers and provides the following functions:
1. Create a specific controller.
Create a controller for a specific subclass without modifying the caller code. For example, if receivecontrollerext type extension has been loaded when the service is specified to construct the receivecontroller, controllerfactory will return the receivecontrollerext type instance to execute the extended business logic.
2. automatic mounting of controller events.
If the Controller declares other controllers that are dependent on, the Framework automatically calls the relevant hook program. For example, movecontroller depends on receivecontroller and uses the method in controllerfactory to declare that it needs to listen to the received event in receivecontroller. Controllerfactory also creates a movecontroller instance when creating the receivecontroller and causes it to be mounted to the receivecontroller. Received event. In this way, you do not need to change the receivecontroller code.

 

In fact, the whole design mainly uses the "simple factory model" to encapsulate the construction process of the Business controller and achieve the expansion effect.
However, in object-oriented design, virtual method extension and event extension are the most commonly used extension designs (Framework Design Guidelines 2nd edition). at the same time, the design of the Business controller basically requires these two types of extensions. Therefore, let's summarize the commonly used Controller Design for ease of use.

 

 

 

 

--------------------------------

Attached. After using this solution, the restructuring results of the Controller in the entire warehouse system are as follows. Before decoupling:

After decoupling:

 

Simplified graph. Before decoupling:

After decoupling: