I chatted with my colleagues yesterday and asked my colleagues a question. Since we already have such an excellent framework as spring and equinox, is it because we are working on the system, you can ignore the system architecture. This seems to be a very simple problem, but after studying the system, I think it is helpful for us to understand the framework, system architecture, and design pattern. For a basic software development framework like spring, the framework itself does not solve the problem of the system architecture. It just helps us implement a system architecture with better scalability. Of course, this is not applicable to the domain framework. This article does not discuss the issue of the domain framework. Therefore, if there is no special description below, the framework mentioned above refers to the basic framework. As discussed in the previous article, the Framework provides a runtime container for extensible components. The framework is responsible for managing the lifecycle of extended components, it is also responsible for coordinating the dependencies and injection relationships between components and components (called services in osgi. However, the framework itself is not responsible for the logical relationship between components, especially the business logic. Therefore, even if we use a framework, the dependency between each component on the business logic is still what the system designers who are familiar with the business need to do. To give a simple example, when a service operation occurs, we need to send a notification to the user. The notification starts with an email notification, in the future, an SMS notification or instant messaging tool may be extended, or another application system will be notified to trigger some processing. Obviously, we can use the observer mode for such a requirement. Therefore, we can define two types of components. An event source component is our own system. This component announced that it can reference multiple listener components; the other is the component that monitors system changes. It may be another system or the component that sends emails. Then, all listeners can be injected into the event source component using spring. Throughout the process, from requirement analysis, to design, component implementation, and component assembly, spring only helps us to assemble system components, and the dependency between components, it is still self-designed on the premise that we fully understand the business needs. The main role of a framework is to help us assemble components. However, it is often a widely accepted framework, and its designers will also, based on their rich project experience, the architecture problems that many application systems usually encounter are provided directly in the framework. Such as transactions, logs, and persistence. We can collectively refer to the components that are not implemented by the core functions of the business system but are depended on by the core functions as auxiliary business components. For example, spring directly provides a wide range of extension components to help us solve these problems. Different implementation organizations of osgi also add various distinctive auxiliary business components in their own implementations. Therefore, to sum up, the adoption of the framework can be said to be a powerful tool to achieve the design ideas of an excellent system architecture designer, the framework helps us to easily implement a highly scalable, maintainability, and reusable system designed by senior designers, it also helps us easily implement systems designed by senior designers to comply with design ideas, such as the "open-closed principle" and "dependency reversal principle.
