Summary: My favorite software architecture-layering, modularity, and osgi

Software System deconstruction is a relatively abstract concept. According to my understanding, it can be compared to a bookshelf. The bookshelves are generated as follows: (1) there are not too many books and you can do whatever you want. It is not too messy, difficult to classify and search; (2) more and more books are produced, do you need to consider horizontal or vertical arrangement? It is easy to skip horizontal arrangement, and it is difficult to find what you want and the books you want. If you arrange them vertically, it is easy to find the books you need, but it is too dominant, in addition, if you put a long-haired book in the vertical bar, you need to sort out a few books. (3) Therefore, we consider using a shelf, which is divided into several layers, (4) When there are more books, you need to add a grid to each layer and tag each book and grid. (5) over time, the bookshelves form a library. The function of software architecture for software system construction is similar to that of bookshelves for libraries. At the same time, the exploration of software architecture is similar to that of human beings for Library Architecture optimization. This metaphor is just a preliminary understanding of its concept. I will not discuss its theory here. If you are interested, you can read a book directly. This article will discuss a favorite architecture. A software system provides users with a number of features, each of which I think is a vertical software Code The execution process. In other words, the software system is composed of horizontal functions, and the application of each function is a vertical code execution process. For example, if you want to query a stock market, it will input some information to the software system, the software system obtains user input, performs verification, queries business logic processing, routes data to a certain network terminal, runs query services, executes database access, returns service results, performs business logic processing, and presents data to users. interface, this behavior is vertical from the perspective of execution of software system code. In this vertical behavior, each activity is associated with the previous and subsequent activities, and the Code also shows a direct dependency. In this case, the classic Hierarchical Architecture classifies the vertical code of the horizontal software functions, thus dividing the layers. The initial layered structure is a three-layer architecture, namely, the vertical behavior of each function of the software system is divided into the business layer, logic layer and data access layer. As the software system becomes increasingly complex, developers abstract more types (layers) of activities for the software system, and there is another layer-7 classic hierarchy. For a single-slave software system, its complexity consists of horizontal (system function) Complexity and vertical (involved business logic and technology) complexity. The emergence of layered structures makes it easy to focus only on the vertical complexity of software. For more complex software systems, we need to divide them into more layers. However, the more layers, the more complicated layer dependencies, and the more complex the development and debugging. In my opinion, it is against the "kiss" principle. Of course, some people may say that this is already the best solution, that is, the most helpless and optimal solution for complex systems. Fortunately, people have discovered these problems and derived a series of classic development frameworks, such as MVC/MVP/mvvm, IOC, AOP, and Orm. The emergence of these frameworks greatly reduces the complexity of complex systems. However, a large number of applications of the framework reduce the complexity of the system. At the same time, it also means that we need to pay a corresponding price to use these frameworks and introduce more programming rules, from another perspective, it also increases complexity. For example, an object directly depends on another object, which is simpler than an object relying on another object through the IOC container, because the latter is not intuitive and a new framework is applied. Therefore, this hierarchical architecture that focuses only on the vertical activities of software has great defects. (PS: for the IOC framework, it is best not to use it for me. I think the biggest attraction to us is that we can directly modify the configuration file or change a small amount of code as needed during the development project, avoid endless changes to users. Of course, IOC applications also improve code testability. However, there is only a little bit of real value for using IOC. Therefore, I just feel that I can do it as needed. I used to like code with art. What is code with art? That is to say, there must be technical content. Simple is art !). Therefore, I want to start with horizontal complexity and perform modular cutting on the system to make every module as independent and simple as possible. A module with low vertical complexity is not required for any framework, and we can divide the layers of each module based on the vertical complexity of the module. However, we have to solve the problem of introducing modular system architecture: (1) how to assemble modules? (2) how to solve the module dependency? (3) how to ensure the independence of modules to reduce the mutual influence between modules? (4) How to develop, debug, and deploy modules? The proposed osgi specification solves all problems of modular applications for us. For (1), in osgi, each module is called a bundle, that is, a service package, which consists of a bundle list file, code file, and resource file. The osgi framework can load modules from a file, folder, or URL. Osgi fully defines the units of the modular application system. For (2), osgi provides two methods to solve the module dependency: 1) when coding a module, one module reuses the functions of another module, it is solved through the import, export, dynamicimport, and require configurations of the module list; or a module inherits or uses the classes of another module in the definition of methods and fields, it is defined using the use command. 2) The module uses the services provided by another module. This dependency can only be reflected in the module running process. For (3), the osgi specification strictly defines the framework class loading mechanism. The classloader proxy network of Java ensures that osgi can create an independent type space for each module, avoid inter-module type interaction. For (4), IDE and osgi specifications have provided simple and perfect support in the development and deployment processes. For local debugging and remote debugging, IDE and runtime virtual machines are also perfectly supported. Summary: My favorite software architecture is modular (plug-in) + SOA! Cutting complex application systems through modular ideas, solving module dependencies through manageable services, minimizing the use of frameworks and modules, and making everything simple, achieving "Simplicity is art ".