Model-Oriented Software Architecture 4-distributed computing model language (1)-from chaos to structure (1)

1.1 Domain Model

Create a model to define the business responsibilities of the system and the scope of its changes. The model element is a useful abstraction for the application field. Its roles and interactions reflect the workflows in this field.

We can use appropriate methods to create domain models, such as domain-driven design and domain analysis, as well as some methods dedicated to domain changes, such as universal/diversity analysis and feature modeling. Domain-related models can further support the creation of Domain Models. They can provide classic solutions for public abstraction and repetitive work in this field, including possible variants of these solutions.

 

1.2 Layers

Regardless of the interaction and coupling between different parts of the software system, we hope to develop and improve the software independently, which may be related to the size of the system or the time to market. However, if there is no clear and rational division of different aspects of the system software architecture, it is difficult to support reasonable interaction between different parts, and thus independent development.

Therefore, multiple layers must be defined for the system to be developed. Each layer has clear and specific responsibilities.

The layers architecture defines horizontal division of software functions based on (sub) system-level attributes, so that each group of functions is clearly encapsulated for independent improvement. Specific criteria can be defined by different dimensions, such as abstraction, granularity, hardware distance, and change rate. For example, the architecture is divided into the presentation layer. The hierarchy of the application logic layer and the persistent data layer is divided from the abstract dimension. The Business Object layer is introduced, its internal entity units are used by the business processing layer, which is divided by granularity. The system is divided into the operating system abstraction layer, the layered mechanism between the communication protocol layer and the application function layer is divided by hardware distance. The divided functions can be upgraded independently by using the change rate as the layered standard. Multiple dimensions are used in implementation applications.

The key issue for layers is to determine the appropriate layers. Too few layers may not be able to fully split different problems in the system for independent upgrades. On the contrary, too many layers can easily lead to an excessively fragmented software architecture without clear views and categories, making it very difficult to improve. In addition, the more layers are defined, the more intermediate layers need to be crossed by end-to-end control, and performance problems may be introduced, especially when the layer and layer are remote.

 

1.3 Model-View-Controller

User Interfaces tend to change. Some of them must support multiple appearances, while others must meet the preferences of specific customers. However, changing the user interface must not affect the core functions of the application. This part is usually independent of the appearance and has fewer changes.

Therefore, an interactive application is divided into three independent parts: processing, input, and output. The change propagation mechanism is used to ensure the consistency of the three parts.

Encapsulate the core functions of an application into a model, which is independent of the specific user interface view and mechanism. When an aspect of the model needs to be displayed on the application's user interface, introduce one or more self-complete views to it, and associate each view with a series of independent controllers, to receive user input and convert it to a model or view. In this way, the user can only interact with the application through the Controller.

Connect the model, view, and controller components through the change propagation mechanism. When the model status changes, it notifies all views and controllers to make corresponding changes, so that they can update their statuses in a timely and accurate manner through the model API.

The Model-View-controller implements the separation of duties of applications with different change rates, so that they can be improved independently.

 

1.4 presentation-extract action-control

The man-machine interface allows users to interact with applications in a specific "Mode", such as forms, menus, and dialog boxes. However, it is best for some applications to operate on different function types through different interface forms.

Therefore, interactive applications are structured to form a hierarchy composed of multiple decoupled proxies: A top-layer proxy, several middle-layer proxies, and many bottom-layer proxies. Each proxy is responsible for a specific function of the application and provides it with a specific user interface.

The underlying proxy provides self-complete functions that users can interact with, such as management tasks, error handling, and data operations. The middle layer proxy coordinates multiple related underlying proxies, such as displaying all views of a specific data type. The top-layer proxy provides core functions shared by all proxies, such as accessing the database.

The presentation-aggregation action-control architecture helps connect multiple self-Complete subsystems, or even connect the entire application. A dedicated human-machine interaction model is used to form a centralized (distributed) system. The disadvantage of this method lies in its complexity: multiple user interfaces must be provided, and when the control flow is dispersed in multiple subsystems, when you need to respond to or update the view in the relevant user interface, you must carefully and clearly coordinate the actions triggered by a user interface. Therefore, the presentation-extract action-control architecture is of practical value only when the software system is not implemented in a single user interface mode.

 

1.5 microkernel

Some applications have multiple versions. Each version provides users with different feature sets, or is different from other versions in specific aspects, such as the user interface. Despite their differences, all application versions should be based on a public architecture and functional core.

Therefore, the plug-and-play mechanism is used to expand a public and minimal kernel to build different versions for the application.

Microkernel enables sharing of all versions of an application and provides infrastructure for integrating features specific to a specific version. Internal servers provide self-complete functions for specific versions. The external server implements the user interface or API of a specific version. To configure a specific version of the application, we only need to connect the corresponding internal server and microkernel, and provide an appropriate external server to access its functions. Therefore, all application versions share a common feature and infrastructure kernel, but they provide different feature sets and visual experience.

The microkernel architecture ensures that each version of the application can be tailored to its purpose. The user or client system only obtains the required features and visual experience, and does not introduce any overhead for the features they do not need. Generally, to improve a specific version to include new or different features and features, you only need to reconfigure the appropriate internal and external servers. The microkernel itself is not affected by such upgrades, existing internal and external servers and other application versions are not affected. In addition, the microkernel architecture reduces the cost of developing and maintaining all the members of the entire application system. Each Service, user interface and API only needs to be implemented once.