How should we understand the variability of architecture design?

hello, Hello everyone , I'm Zhang Zhang ,「 The road to the advanced architecture 」 The public name author .

One 、 Architecture design layering

Usually , Our architecture design diagram will probably look like the following figure , Let me start with a statement , There's nothing wrong with this , This is also a typical layered design ~

Specific description of each layer , Let's just talk about it .

• Client layer

This is simpler , Not much .

• Business Logic

The business logic layer is divided into Manager and Engine layer ,Manager Responsible for managing the variability of process classes ,Engine Responsible for the variability of an active node itself .

What is process variability ？ Simple understanding , It's workflow .

The following two processes are exactly the same , Only the activities used in the second step are different , If B and D Doing the same thing , that B and D Should be encapsulated in the same Engine in .

Of course , If B and D Function differently , Then the two processes are different , Another theory .

• Resource Access

This layer is the resource access layer , Responsible for the encapsulation of some storage resources , That is, when the company's infrastructure needs to change , It should not affect the business of the upper level , This kind of DDD The community also has Repo Pattern And so on. , It's easy to understand .

• Utilities

Those purple components , Generally, it is some common non functional SDK, It's easy to understand .

Most of the modules in the architecture diagram are services ：

Such layering is solved every time Who、What、How、Where These four questions ：

From the top down , Variability is gradually reduced , We can understand this , The most common changes in the company are some of the above business logic , It's good to change the underlying infrastructure once a few years .

Top down reusability is increasing ,Manager Make frequent changes 、 restructure 、 Completely rewrite , It's all quite normal .

Two 、 Architecture combination design scheme

• Open architecture

Any component can call any other component , Regardless of the layer where the component is located . You can call... Up and down .

The development architecture has great flexibility , However, it will obviously lead to mutual coupling between layers , Horizontal calls within the layer can also lead to mutual coupling within the layer , Such projects cannot be maintained .

The author believes that horizontal invocation is one of the consequences of the decomposition of architecture according to function .

• Closed architecture

Closed architecture prohibits horizontal calls within the layer , And prohibit the lower layer from calling the upper system .

In this way, we can give play to the advantages of layering , Decouple layers from one another .

Closed architecture only allows components in one layer to call components in adjacent lower layers , Lower level components encapsulate lower level logic .

Semi closed and semi open architecture

Key parts of infrastructure , Sometimes it's hard to avoid calling each other . Because infrastructure needs to consider performance issues , Must be optimized to the maximum , And sometimes down conversion can lead to performance problems .

But most systems don't need to be half open and half closed , Just close it .

Relax the rules of closed architecture

Because the requirements of closed architecture are too harsh , There are problems in actual development , In the following cases, it can also be relaxed as appropriate ：

• call utilities

• Access resources according to business logic , namely manager Layer direct call resource access layer

• manager Components call less adjacent engines

• manager Component to other manager Components through MQ To communication , This situation manager Components do not need to know other components , Just send message That's all right.

• Design taboos

The following behaviors are not allowed ：

• Client You should not call more than one use case Manager, You should not call Engine

• Engine No news should be released , Should not subscribe to message queues

• Engine And Manager Should not call each other

3、 ... and 、 summary

About composable architecture and architecture validation , Be sure not to design according to your needs , But design according to variability .

When designing the system , To find the core requirements from the requirements list , After the design is completed , First, use the core use case to verify the architecture . When new demands are added , There should be little need to change the architecture , This shows that the architecture design is right .

The functions in the system are the result of integration , Not the result of implementation .

  welfare ： Pay attention to the official account reply key ： restructure , Free access to 《 restructure ： Improve the design of existing code 》

·················· END ··················

Official account , Free learning materials

Ten years of R & D , Big factory architect ,CSDN Blogger

Focus on architecture technology learning and sharing , Career and cognitive upgrading

Insist on sharing the dry goods of the earth , Looking forward to growing with you

---

「 The road to the advanced architecture 」 Focus on Architecture Research , Technology sharing

I'm looking at one less bug

This article is from WeChat official account. - The road to the advanced architecture （jiagou_jingjin）.
If there is any infringement , Please contact the [email protected] Delete .
Participation of this paper “OSC Source creation plan ”, You are welcome to join us , share .