Shulou(Shulou.com)06/03 Report--

This article mainly explains "the process analysis of plug-in evolution from monomer". The content of the explanation in this article is simple and clear, and it is easy to learn and understand. let's study and learn the process analysis of plug-in evolution from monomer.

Recently, I ran into a variety of decision-making difficulties when optimizing a hierarchical architecture for Coco. So I keep delaying decisions to find out what is more suitable for the existing system. To put it simply, hover on the brink of danger, hoping to get the most out of it.

When designing a new architecture, we always rely on our previous experience, combine the current needs of the business, and make our design according to the needs of the future. That is:

Past experience.

What we need now.

The future direction.

Under the influence of various factors, it is doomed that we will not be able to design a system that meets all historical periods. The future will become the present, the present will become the past.

Coco Architecture Design: from the past to the Future

There are many factors, such as the various design problems of Coca, as well as the support of Golang for multiple platforms. Forcing the Inherd open source team to consider designing plug-in systems for Coco at the initial stage of Coco. Until recently, after we implemented the plug-in system, we found that the originally designed hierarchical architecture can no longer meet today's needs.

Although I already know how the new hierarchical architecture should be designed, I don't want to go in that direction. I'll take a detour and see if there are some more interesting designs.

Original form: monomer architecture

In the early days of my design, I introduced a hierarchical architecture design similar to Clean Architecture in Coco (without Cargo modules):

App, which corresponds to the usecases.

Bin, corresponding to controller. In the Rust build system, the bin directory will be built into executable files

Infrastructure, which corresponds to infrastructure, such as calling Git interfaces, accessing file systems, and so on.

Domain, namely business entity, domain pattern, includes the business design of the system.

Under the domain directory, it is divided twice according to our four basic businesses:

Cloc

Git

Framework

Architecture

……

Although, I keep saying that I use a hierarchical architecture similar to Clean Architecture. But in fact, some of these important designs are not adopted, such as the problem of controlling the flow direction by relying on reversal. From a personal perspective:

Hongmeng official Strategic Cooperation to build HarmonyOS Technology Community

It brings a certain degree of architectural complexity, which requires the continuous transmission of relevant architectural knowledge, and whether it can be promoted in open source projects is open to question.

It can be transformed later by refactoring. I am not a very senior architecture expert, so it is more convenient to start with learning.

As a monolithic application, this hierarchical structure makes do:

Hongmeng official Strategic Cooperation to build HarmonyOS Technology Community

It's not too complicated, and it allows developers to know where to put the code.

It can be evolved into Clean Architecture on demand.

The module can be further split by business.

The story got off to a good start.

Modularization of reuse form

In order to reuse code between multiple different systems / applications (that is, the code of the Coco project is provided to other applications), some independent modules are produced in the system, such as psa, framework and so on. This is also a very common modular scenario. Modularization has some similarities in different languages.

For example, there are two modes of use: local use and remote publishing. When using it locally, you don't need to pay attention to a series of things such as the semantic version, just focus on the code itself. Once the time is ripe, it can be evolved into a module that can be released remotely.

A typical form of modularization from a single unit is to be presented in a directory at the same level as the source code in the code base. As follows:

├── framework ├── psa ├── src │ ├── app │ ├── bin │ ├── domain │ ├── infrastructure │ └── lib.rs

Framework and psa here are independent modules, and once they are decoupled from the dependencies of other modules, they can be released as independent applications.

Replication over Multiplexing

By the way, for modular code reuse, if the amount of code is small, you can try to copy a copy of the code instead of reusing it. In this way, we can decouple the dependencies.

Plug-in architecture evolution

At the same time, in order to flexibly expand the function of the system, we design a plug-in system. (in fact, more intentionally, we just want to reduce the size of the package so that it can be easily downloaded from GitHub.)

Therefore, we created a separate plugins directory and created the corresponding module in it. The following coco_xxxx is the plug-in. At the same time, we used plugin_manager as the manager of the plug-in (in fact, as later proved, this manager should not exist independently as a module):

├── framework ├── plugin_manager ├── plugins │ ├── coco_container │ ├── coco_pipeline │ ├── coco_struct │ └── coco_swagger ├── psa ├── src │ ├── app │ ├── bin │ ├── domain infrastructure lib.rs

From a design and evolution point of view, there are not many problems and can be used.

Evolution: future of the Future

Well, due to the lack of experience, we are faced with problems that we did not consider before.

Extract core model

From a design point of view, we should have provided a core module in the original architecture model. In this core module, it is used to provide some core code to plug-ins and applications.

So, soon we created a core_model. My original meaning is to provide a core model. I don't want to imagine that some plug-in projects provide a lot of non-core code in core.

However, with the emergence of the first model reuse requirement, there will soon be the second part and the third part.

Another choice: the transformation of the infrastructure layer

In addition to the reuse of models, there will also be infrastructure reuse between plug-ins. I don't want to put this code in core, so I need to extract an infra module to share the infrastructure code. So the question is, how should we choose?

Hongmeng official Strategic Cooperation to build HarmonyOS Technology Community

Extract the original infrastructure into the home directory and exist as a separate module.

Double-layer infrastructure, that is, only extract the common code, to the home directory, as a separate module.

From the perspective of architectural design, I support the existence of a two-tier infrastructure. Copying too much of this common code unconsciously can lead to a further expansion of the package size. A typical example is that we see the existence of the common directory, namely xxx-common.common.common, under a common subpackage in a jar package called the common package.

Summary: the continuous evolution of architecture

That's the end of the story. No matter how small a project is, its architecture pattern will continue to evolve with the development of the system. If it is not controlled, the system may push for control. And the evolution itself will not be plain sailing.

However, I am thinking about a new thing about "hierarchical architecture fitness function".

Yiki: hierarchical architecture fitness function

We are trying to rate the tiering of the system, both in Coco and in Coca. One of the bases of this rating is to confirm the reference relationship between each module through the dependency relationship, so as to judge whether the hierarchical architecture of the system meets the requirements.

By parsing the reference relationship between modules, we can effectively help us to clarify the reasonableness between system modules.

Thank you for your reading. the above is the content of "the process Analysis of plug-in Evolution from monomer". After the study of this article, I believe you have a deeper understanding of the analysis of the process of plug-in evolution from monomer. Specific use also needs to be verified by practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.