System Architecture Based on business module components

Author: Anders James

I have written an article "abstract-based hierarchy". Here I add an article "system architecture based on business module components".
Some content has been mentioned in "project notes: Dao, web, module boundary and model classification" and "Module Interface Design". I will summarize it here.

A system of a certain scale usually breaks down the system to reduce the difficulty of analysis, design, and Development. module division is a common method.
In the division of modules and the practice of analysis and design, there are two levels of boundaries. The first is the interaction behavior level, and the second is the object level.

First, interaction behavior.
The interaction interfaces between modules are the most important. We usually think that these interfaces should be universal and stable. However, it is not easy to design the interfaces provided by each module.

Two basic integration implementation methods:
1. API method.
This is a common practice. That is, each module exposes a small number of interface classes (but has many interface methods) and interface parameters (both common VO ), the Design and Implementation of each interface are maintained by the module members. In practice, these interfaces are packaged independently to form multi-module-to-one dependency for easy compilation.
The advantage is that the interface boundary is clear and the development and compilation dependencies are relatively simple.
However, in practice, there are two very likely situations: the interface maintenance is out of control or too rigid (and affects development ). The interface is out of control because the interface maintenance is too casual, because the module needs to easily add an interface (method) to module B, resulting in this interface (method) non-independence (basically used only for this function of module A), or strict interface control, resulting in low work efficiency, or poor ease of use of interfaces.
The reason is: the interface is the coupling between the two modules, and various problems occur because the module coupling is too tight. In practice, the interface provided by the module is, it is confused with the integration of the external modules that the module needs to implement. In other words, the semantics of the Integration of module A is different from the semantics of the interfaces provided by Module B.
Practical advantages: low development management control costs, simple module compilation dependencies, and clear module physical boundaries.

2. Adapter Method
This practice can solve the problems faced by the API method to a certain extent: According to the guiding principle-to reduce coupling, only one layer is added in the middle; that is, it is not easy to design external interfaces (methods) for the module ), the module provides two types of external services: one is the interface implemented by the external module (the interface design starts from the needs of this module, of course, although each interface serves a certain functional point, it should also be noted that it is universal within the module ); the other is the implementation class of the interfaces that other modules require to implement ).
That is, module A has some interfaces that need to be implemented by Module B (Requirements of module A for Module B), while Module B also has interfaces that require implementation by module, therefore, a has the implementation classes of these interfaces.
In consideration of compilation dependencies, the existing practice is to maintain the code adapted to the processing interface outside the module, that is, the so-called integration module. In this way, compilation Forms 1 (interface implementation) dependency on N (module. The boundary of the module is blurred here. Of course, the boundary of the module outside of this is clear.
The advantage of this practice is that the module interface is isolated to reduce coupling, and the versatility of the interface and adaptability of the interface are separated, and the boundary of the module is also clarified, this provides a buffer for Interface Optimization and adjustment in the future.
The difference between this practice and API practice is that the design right of an interface is divided into two parts, and the demand side has the right it should have, and this right is not in conflict with the provider (the old model is not good, once the supplier changes the interface, the compilation problem is immediately caused ).

Comparison of the two methods:
1. API integration comes at the cost of maintaining the API itself. The API faces a large number of clients, resulting in high design and maintenance costs and high implementation costs;
2. adapter-based integration. Because there is no maintenance API and there is no reusable interface, but it can be customized for each client, its design and maintenance costs are low, and the implementation cost is high;

 Integration evolution:
1. Use the event mode.
This is also the mode for completing interactive processing. Generally, the event mode can also complete functions with the interface in business behavior. However, because it cannot clearly provide its business meaning in the interface signature, we recommend that you use it with caution. For productized projects, the project can begin to apply the event processing mechanism and extract it as a more specific interface when it is mature.
In event mode, the event listening class also faces the boundary issue of the module. Known mature open-source projects all expose internal module objects in the event source for developers to use.
It can be said that this method is the evolution of the adapter method;
 
2. Adopt the framework callback Method
Workflows and page streams are also responsible for integrating different modules. however, because the workflow and the page flow framework both maintain an independent data object sharing pool, direct interaction between modules does not exist at this level. The advantages of this integration have evolved through an ESB and other integration frameworks.
This method is an evolution of the API method, but the call points and the caller are independent and become part of the framework.

Now let's talk about object-level border integration.
In insurance, the benefit object is associated with a product object. However, the product object belongs to the product module rather than the policy module. For the policy module, only the ID is concerned and the object is not used, however, in an integrated environment such as RMS, FMS, or UIC, product objects are required. We need to use the code generation method to add an annotation to the benefit object, such as the annotation identifier of integration, and use aspectj to compile the class generated by enhancement, so that the benefit object can get the product object in the integration environment, which is an integration aspect.

Componentized Management
Componentized management has two meanings:
1. Component Access Control, dependency management, and service registration;
The existing access control method can only be checked when code is submitted or compiled and released, but we prefer to support the runtime capability, avoid external components from accessing components without declaring open internal structures and programs; meanwhile, the maintenance method should be simple and convenient, and the cost is low.
Currently, component dependency management is almost absent, especially version-based dependency. In practice, dependency maintenance management, especially multi-version dependency, usually costs a lot.
2. Binding of component dependencies and isolation of failure (fault;
We want to provide a protection area for each component. When a component on which it depends fails for various reasons (software errors or software upgrades, the system should provide at least one fail-fast mechanism, including the following capabilities:
A. Stop upon failure (halt on failure)-When a component fails, it should be stopped immediately, rather than continuing to perform operations that may be incorrect;
B. Fault exposure property-when a component fails, other components in the system should be notified, and the cause of the failure must be clearly stated;
At the same time, we want this component to continue running if possible. It takes a lot of work to accomplish this goal, but it depends on the system's fail-fast capability first. At the same time, after the Fault Elimination service is restored, the system can provide corresponding notifications and control the recovery sequence.

Known supporting frameworks: SCA and osgi
1. SCA considers heterogeneous asynchronous environments, while osgi considers homogeneous synchronization environments;
2. osgi specifies how containers manage components, component dependency (Version) management, component boundary protection, and component services depend on runtime binding policies and permission control. SCA does not address this;
3. How to expose services and how to use services on the client during design is considered by SCA; osgi is more comprehensive;