Abstract-based layered structure
Author: Anders James
(Updated from)
The existing known layered structures are basically based on the technical structure. Both springside (appfuse) and DDD hierarchical structures are based on responsibility and role. However, for complex enterprise application systems, logic decomposition cannot be completed only by dividing them by this latitude. We also need to use the abstract layered latitude.
Abstract-based layered structure
As we all know, abstraction is arranged. Further, in enterprise applications, abstract arrangement is also hierarchical. At the same time, abstraction is still segmented, and interaction interfaces are well defined to ensure the stability of interaction between abstractions.
Abstract layers are based on business concepts. Taking insurance systems as an example, abstract layers can be divided into three layers: Insurance's core business concept-core abstraction layer, it is also subject to national regulatory rules-the National abstraction layer, and the company's own rules-the company abstraction layer.
If the abstract hierarchy is vertical classification, the module classification is horizontal classification. Module division is common and is not used as an example.
For abstract layering, further description is required. The following is a three-layer abstract description. The white is the core abstraction layer, the water green is the extended abstraction layer, and the sky blue is the specific abstraction layer.
Abstract hierarchy is a way to think about problems in line with human thinking logic, from simple to complex. Note that the core abstraction represented by White has the smallest coverage area and the smallest boundary. The extension abstraction is followed by the specific abstraction. The second benefit to abstract layering is that it can be iterated and spiral forward.
First look at the core abstraction layer: the Core abstraction layer must be delicate and stable, because they are the most basic and simple structure of the system! At the same time, the core abstraction layer can be run! Their abstraction and default implementation are in the whole system-similar to 0 and 1 in a mathematical system! The extended and specific layers with complex changes are similar to 2 and 3 in mathematics. However, we all know that in mathematics, 0 and 1 are the most important, without 0 and 1, A mathematical system cannot be built.
For the abstract level, the question is how to protect the boundaries of the abstract level and ensure that the changes in the upper abstraction level will not cause the next specific abstract change. This requires that the lower abstraction delegate the logic to the new interfaces and abstraction in the extended abstraction layer. This ensures the Basic Semantics of the core abstraction and protects the boundaries of the core abstraction.
The system must support the core abstraction layer to leave extended space for the lower abstraction layer. The basic means is to inject the extended implementation into the core abstraction layer by exposing the factory. In addition to extended, the system also needs to support replacement (override), expose the factory of the core layer, and inject the replacement implementation into the system. Currently many systems based on similar spring, you can use spring's bean override mechanism to complete the process;
Such abstract layers can be maintained independently because they are complete and bounded.
The core abstraction layers in the whole system are 0 and 1. However, when considering the extension of the abstraction layer, this layer becomes the 0 and 1 of its specific abstraction layer, we need to build this layer just like building the core abstraction layer to maintain its completeness, boundaries, and scalability.
As the perimeter of the system expands over and over again, more and more functions are provided by the whole system, more and more scaling points, and more dynamic features are supported by the system!