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

Author | Senior Technical expert of Yi Ali Culture and Entertainment

Follow the official account of "Alibaba Cloud Origin" and reply to the structure to see a clear knowledge picture!

Guide: what is the architecture diagram? Why easel composition? How to draw a good architecture diagram? What are the ways? This paper starts with the definition of architecture, shares the experience of Yi Yi, a senior technical expert in Ali entertainment, on easel composition for many years, and discusses the concept of abstraction in depth. The content is long, so students can collect it and read it carefully.

What is an architecture diagram?

How to draw a good architecture diagram, in order to do this thing, the first answer is what the architecture diagram is. We often see a variety of architecture diagrams in our daily work, and we often find that people have different emphasis on their understanding of architecture diagrams. If we go deep into this issue, it may be very difficult to have a concrete definition all of a sudden. If we split this issue, it will be easier to understand.

Architecture diagram = architecture + diagram

According to this equation, we can change the problem:

What is the architecture? What's the picture?

What's the picture? This is easier to answer. A diagram is an expression of information, so an architecture diagram, that is, a diagram that expresses "architecture", is an expression of architecture. That is, the architecture diagram = the expression of the architecture = the diagram expressing the architecture.

According to this line of thinking, we need to answer:

What is architecture? What exactly are you trying to express? How to draw a good architecture diagram?

The following content is basically based on these two dimensions to do the analysis.

What is architecture? What exactly are you trying to express?

Linus'03 has a good description when it comes to split and integration:

I claim that you want to start communicating between independent modules no sooner than you absolutely HAVE to, and that you should avoid splitting things up until you really need to, because that communication complexity often swamps the complexity of the actual pieces involved in it. (let's realize the phenomenon that splitting a complex system into modules does not seem to reduce the complexity of the whole system. It only reduces the complexity of the subsystem. On the contrary, the complexity of the whole system will become more complex because of the interaction between the split modules. )

I understand that the system split described here is the process of architecture, the basic starting point is for efficiency, through a reasonable split of the architecture (whether spatial or temporal split), the ultimate goal is to maximize efficiency. In fact, there is no completely unified and clear definition of what is architecture. The following three definitions can be used for reference.

The definition on Baidu Encyclopedia:

Architecture, also known as software architecture, is an abstract description of the overall structure and components of the software, which guides the design of all aspects of the software system.

Definition on Wikipedia:

Architecture is both the process and the product of planning, designing, and constructing buildings or any other structures.

Architecture is defined in ISO/IEC 42010VO20072 as follows:

The fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution.

These three definitions also vary, but we can basically conclude that architecture reflects the relationship between the overall structure and components.

1. The nature of the architecture

Here are three points to explore the nature of architecture:

The essence of architecture is to manage complexity.

The essence of architecture is to reconstruct the system in order to reduce the "entropy" of the system and make the system evolve continuously.

The essence of the architecture is to restructure the system in order to meet the current business development and can be expanded rapidly.

The contents mentioned in the above three viewpoints basically express the core purpose of the architecture: management complexity and efficiency maximization. And the two main sources of architecture change: one is the internal structural change for the purpose of improving software quality, and the other is the external functional change for the purpose of meeting customer needs.

No matter what kind of change, in my opinion, the architecture is constantly judging and choosing, making a trade-off between business requirements and system implementation, so as to deal with the uncertainty of future changes, such as the following figure can express this understanding shallowly and intuitively.

two。 What are you trying to express?

In the field of EA architecture, there are two common architectural methods, RUP and TOGAF, which are also two dimensions that we often understand about architectural classification. From a personal point of view, I think TOGAF's classification is more widely used (see figure below).

Combined with daily business development, in fact, we pay more attention to business architecture and application architecture, so we further disassemble the above expression. Before answering how to draw an architecture diagram, we need to pay attention to business architecture and system architecture, and discuss how to implement business architecture and system architecture.

3. The process of architecture is actually the process of modeling.

We all know that the process from the real world to the software world or the object-oriented world is a process of continuous abstraction, in which the method is to constantly build models. From the real world to the business model, from the business model to the conceptual model, from the conceptual model to the design model, through continuous abstraction, the layer-by-layer abstraction of the real world is formed, so the process of architecture is actually the process of modeling. At this point, it is necessary for us to understand what modeling is.

Baidu encyclopedia definition:

Modeling is the establishment of a model, an abstraction of things in order to understand things, and an unambiguous written description of things.

Definition of "Thinking in UML":

Modeling refers to establishing an abstract method to represent things and gain an understanding of things themselves, conceptualizing this understanding and organizing these logical concepts to form an easy-to-understand expression of the internal structure and working principle of the observed object.

From the above two definitions, we can basically understand that modeling is abstraction. Although the abstraction of business or real world is not enough to help us understand the architecture itself, we can further Down the business architecture and system architecture we are concerned about above. The process of architecture is the process of modeling, and we transform it into two simple questions: what is the module? How to build it?

4. What is Mu? How to build it?

These are two problems that are easy to fall into theory, and we jump out and look at the process from the results. Then use some of the architecture diagrams that have been produced to reverse how they are produced, and answer both questions at the same time.

1) Business modeling

Going back to the current business itself, it is also new to me. When I first came into contact with it, I understood it with the only industry background. Combined with a large number of documents, I finally produced the "business core flow chart" and "business function module diagram" shown below. These two pictures basically cover all the business content. The business flow chart on the left is recognized by experts with more than 20 years of experience in the industry, who believes that this is the content of the business he has been engaged in for more than 20 years.

The picture comes from the network, as a schematic diagram, invading and deleting

Looking back at the whole process, especially the business core flow chart on the left, today we see that this flow chart is easy to construct a basic logic, vertically is different business roles and systems, horizontal is the advance of time, it is easy to understand. But I want to say that the initial understanding and analysis is an extremely time-consuming and stressful process. The method I use in this process is:

"read the book thick": enter a large amount of information and explore possibilities at the same time; "read the book thin": classify and summarize to form a large picture; logical comparison to ensure the correctness of understanding and analysis.

Read the book thick:

The following figure basically covers the process of "reading the book thick", gathering a large amount of document information and trying to form logic with multi-dimensions. This dimension may be based on historical experience or on the content of the document. For example, in the process of forming a business map, I have classified the contents of multiple documents according to possible scenario logic, possible system or domain logic. Explore possibilities.

This process can be boring, especially when it comes to some business terms, which can be difficult to understand. My way is to think of myself as an "explorer". Just as we play games, I often ask myself, "have all my game maps been lit?" You may not have to take care of all the details, but you need to try to cover the whole content. When you think about it, it seems to be similar to daily reading, during which it is worth noting that:

Focus on some areas where business concepts are defined and where they differ from their own logical reasoning.

Constantly adjust the dimensions of the records in the process of reading and correct the direction of analysis.

Honestly use the original words in the document to record and present (this is very important, especially reading English materials, preferably authentic records, help to improve your professionalism).

Read the book thin:

The focus at this time is to establish "overall vision" and try to sort out its own logical main line. Conventional logic will be divided into horizontal and vertical, or matrix framework, of course, which needs to be based on early understanding and analysis. Here often implies the most important assumption: the system must be for people, must be to solve customer problems, otherwise there is no significance. So the core routine is: who? What kind of services / functions / capabilities are used? What kind of problems do you solve? In order to depict: the role of participants, system capabilities, interactions, you often need to ask yourself: what is the boundary? What is the input and output? Gradually sort out the business function through the use case, form the role-> main process-> branch process, and then form the final business abstract description "a diagram" through continuous induction and deduction.

A small detail is that we cannot attempt to quickly complete the drawing of a large picture in the brain through these processes, or we need to start with a small link and turn a part of the small business closed loop into a small block one by one, so that it no longer takes up the space of the brain. then gradually think and grasp as a whole, gradually form a large picture; at the same time, the beauty of the big picture is completely ignored, and then the logic is carefully adjusted. This detail is emphasized because it is challenging to try to describe a very large business through "one picture". If you do not do so, it is easy to become anxious and impatient, which is slow and patient. you need to slow down in key blocking places, or even repeat it over and over again.

Logical comparison:

This is a closed-loop encapsulation process, in which the records, logical details and key processes of the previous "read thick" process are put into the big picture one by one to ensure the completeness and accuracy of business understanding. ensure that the business abstraction can cover all known business use cases and even support possible business scenarios. This link is also an essential part.

To sum up business modeling (such as the following figure), through the above three main processes, we can basically produce some business architecture diagrams, block diagrams, flow diagrams, use case diagrams, etc., what kind of diagram is not important, the important thing is who is this diagram facing? What is it mainly used for? I will also talk about the angle of drawing later. From our current business scenario, the core purpose of the business architecture diagram is to unify consensus and reduce communication costs. No matter which role in the project, everyone can say the same thing and describe the same thing. This is to establish dialogue ability and dialogue context, especially when there are a large number of external customers, on the one hand, it is important to reflect our own professionalism, on the other hand, this ability of dialogue with customers is more important. This is also why it is mentioned above why we should present a picture as authentic as possible.

2) system modeling

The construction from the real world to the business model is completed through business modeling. on this basis, how to map the business model to the design model through abstraction is the problem to be solved in system modeling. From the perspective of R & D implementation, this stage will produce a variety of model diagrams, such as entity model diagrams, sequence diagrams, state diagrams, architecture diagrams at all levels, etc., but no matter what angle or level, system modeling must complete the mapping from business requirements to system models on the basis of business modeling, which involves the mapping of business functions to system capabilities, business processes to data processes. System modeling emphasizes the relationship of responsibility, dependence and constraint, which is used to guide the implementation of R & D.

Leaving aside the specific timing diagrams and state diagrams, take a brief look at the architecture diagrams of the following dimensions:

The picture comes from the network, as a schematic diagram, invading and deleting

The perspective, level and user-oriented of the above pictures are different, basically you can see the whole, but the level of detail is different, the emphasis on the expression of information is also completely different. So what should I do when modeling the system? the method I often use in this process is (not necessarily):

"peeling onion" from large to small, from coarse to fine, covering all known and future possible business scenarios; good at using a variety of model expressions: natural language, relational models, sequence diagrams, state diagrams, flow diagrams, various hierarchical architecture diagrams, etc., fully express various business scenarios and constantly verify

Core entity extraction: grasp the core concept, the core relationship to complete the core model establishment

Ultimate weapon: all the design / logic ambiguous points, put all the known scenarios separately, and tell it to yourself.

"peel onions":

"peel onions" based on the results of business modeling. This is a continuous disassembly process, and a very important way of disassembly in this process is the division of labor in the system. How to divide the work? Which module is responsible for what? What are the inputs and outputs of the module? What kind of services and capabilities are provided internally? These questions are answered later in the section on abstraction. In a word, "peeling onions" is: from the business modeling of "overall vision" to the division of responsibilities to disassemble into multiple subsystems, multiple sub-modules, and then in the module can be subdivided, layer by layer stripping.

Core entity extraction:

With regard to the extraction of core entities, the key question here is: which are entities? How to judge the core entity? How to extract it? What is the result after extraction? It is difficult to describe it in a methodological form, and I have not completely formed my own immutable methodology, but I think the following three ways can be used for your reference.

Analysis method of object

Entity: things that exist objectively and can be distinguished from each other are called entities. Entities can be concrete people, things, things, or abstract concepts or connections.

The understanding from this concept is basically consistent with our object-oriented understanding of everything and objects. Therefore, entity extraction can also learn from the methods of object analysis: independent, abstract, hierarchical and atomic at a single level. The following figure shows the analysis methods for objects in "Thinking in UML".

The method of use case Analysis

By extracting keywords from business use cases, different keywords may express entities, relationships, attributes and so on, so as to complete the analysis and establishment of the model. Here, I quote the content of teacher Liu Baht in "basic Abstract methods of problem Space Domain Model", which is briefly described as follows:

In a complete use case description, first find nouns, mainly "subject" and "object", these nouns can basically determine our entity; secondly, find adjectives, which exist in "attributives" and "adverbials". Find adjectives can basically determine the value of the corresponding attributes; then through the supplement of the use case, refinement, the definition of nouns, slowly, we will get our domain model and corresponding attributes. Finally, the relationship between them is determined by verbs-adjectives (which exist in [predicate], [adverbial], [attribute]).

The method of problem analysis

This is the way mentioned in "chat Architecture". Specifically, by finding the subject of the problem, and then analyzing the life cycle of the subject, and then by distinguishing the key activities in the life cycle to focus on the key attributes and key relationships of the subject. It is recommended that you read the first 9 chapters, a total of only 40 pages, you may have some experience. Here's an example from a book:

A joke: a woman said to her husband: cut half the potatoes in the bag and put them into the pot; as a result, all the potatoes were put into the pot, and each potato was cut in half.

The author points out that there is no clear setting subject here, this subject is not only potatoes, but implied that people want to eat potatoes, including people and potatoes two entities, the relationship between these two entities is to solve the business scenario: how to eat? How do you eat it? Why are you eating? Therefore, the subject identification is not clear, which may lead to the deviation of the overall implementation. Of course, we will not make such stupid mistakes in the actual process, but it also shows that the extraction of core entities is very critical.

Ultimate weapon-tell yourself:

In the actual business development, one kind of business design and implementation often has to meet the upper N business scenarios, in which there are similarities and differences as well as personalized demands. In this process, we are easily confused by the similarities and differences between multiple scenarios. Either the logic is not clear, or overdesigned, or ill-considered. I have observed that many students, including myself, tend to lose the focus of design when there is a certain business complexity. My approach is similar to business modeling, which must be logically compared: at all the points where the design / logic is vague, apply all the known scenarios separately and tell yourself. Please note that this is "embedding separately". After verifying one scenario under the current design level, we will verify the next scenario, find out the blocking and fuzzy points, and re-comb and optimize the design. The results of system modeling guide our software design and implementation, so we must repeatedly comb through, this repeated process is actually a process of improving architecture capabilities, accumulated to a certain extent will be naturally transparent.

Back to the question at the beginning:

What is Mu? Through the above description of business modeling and system modeling, simply speaking, a model is a business mapping, and the result of this mapping is a business model, a conceptual model, or a design model, but all the starting points are business requirements: who is the customer? What is the core demand?

How to build it? The above roughly talks about the routine from the perspective of personal practice through the two dimensions of business modeling and system modeling. The essence of modeling is actually an abstract process. However, there are still two problems in the abstract process of business and system modeling that are not fully explained:

In business modeling, "reading books" is classified and summarized, and "overall vision" is established to form a big picture. what dimension is it classified here? How to judge that the classification is correct?

How to remove "peeling onions" in system modeling? Press what? How are the levels and domains in the above architecture diagram divided? Where is the boundary?

Back to abstraction.

Paul Hudak, one of the designers of the Haskell language, once said a slightly exaggerated sentence: the three most important things in programming are: abstract, abstract.

"abstraction, abstraction, abstraction" are the three most important things in programming.

If you want to ask programmers what are the most important abilities, I believe that abstraction must be one of the most important. So what exactly is abstraction?

Baidu encyclopedia definition:

To extract and summarize their common aspects, essential attributes and relations from concrete things, while abandoning individual and non-essential aspects, attributes and relations, this thinking process is called abstraction.

If a more concise summary: abstraction is to do subtraction and division. By abandoning the non-essential and unimportant parts, focusing on the nature of the problem, getting rid of the rough and refined; through the phenomenon to see the essence, to find the common ground between different things, seeking similarities in differences, merging the same kind, that is, doing division. The modeling process above is a general abstraction. Until a certain state is reached through continuous abstraction, I understand that there is no definite answer to this state, and the core is to meet the needs of business scenarios. In fact, there is also a boundary problem behind this.

1. Abstract point of view

Life is full of abstractions, but we seem to have less thought about why they are abstract in one way or another. Abstraction is divided into angles.

In life, we often say, "my point of view is..." In fact, the "point of view" here is a question of angle, the view of things or problems from a certain position or angle. In terms of the common objects in life (such as the picture below), can we quickly tell the similarities and differences?

As already noted in the picture, we define chairs, tables, stools and cabinets from a functional point of view, but there are obviously many angles, such as material, text, height, and so on. There will be completely different similarities and different expressions, so what is the essence? The essence is:

In fact, the abstract point of view is also the angle of classification, and different angles will lead to completely different modeling directions and results.

The abstract point of view is the direction and purpose of modeling ("buttocks determine head").

Going back to the two questions before us, in business modeling, we talked about classification, what to classify, the answer is coming out, according to our business process, by the role of the customer, back to the original question: who is the customer? What is the core demand?

At the same time, we mentioned above that a module is a business mapping, and based on the understanding of abstraction, we can further expand: a module is a business mapping from a definite abstract point of view.

two。 The level of abstraction

In Wikipedia's definition of abstraction, there is an example of newspapers:

My May 18 San Francisco Chronicle, May 18 San Francisco Chronicle, San Francisco Chronicle, a newspaper and a publication

In these five sentences, we can feel the level of abstraction, the higher the level of abstraction, the less detail, the stronger the universality. For example, in the following figure, about the abstraction of the network model and the abstraction of the operating system kernel, we can obviously see different levels of abstraction, that is, filtering different information, and the information left behind is the information needed by the current level of abstraction. In terms of system design and implementation, the higher the level of abstraction is, the closer it is to the design and the farther away from the implementation. At the same time, the abstract model is less fettered by details, and the higher the stability, the stronger the universality, the higher the reusability.

So what is the basis of the abstract hierarchy here? What is the principle? In my experience, there are two main bases for dividing the level of abstraction:

Layering from an abstract point of view (perhaps one layer is a multi-angle aggregation) to face the change layering (using layers to isolate changes)

In fact, this does not fully explain how to layer, what is the principle? I think these are some of the most general principles:

The public going down, the personality going up, the lower layer can control the change of the lower layer independent of the upper layer.

The advantage of considering the level of abstraction is that at any level, we only need to face a limited complexity so as to concentrate on what the abstraction at this level is and what the information is to express.

3. Abstract boundary

In addition to angles and levels, we also need to consider abstract boundaries. If the hierarchy considers the expression of the vertical dimension, then the boundary considers the expression of the horizontal dimension. How to determine the boundary, a general principle is to divide according to the responsibility, the responsibility here is actually the division of labor. Once the responsibilities are determined, we do not need to analyze the overall situation of the whole business from beginning to end when we do modeling and analysis. we only need to consider the upstream and downstream under the current division of labor, so the amount of information is greatly reduced. naturally, the complexity of the domain we face will also be reduced to a certain extent.

If the definition of the boundary must be given, my understanding is that the boundary is the result of the core life cycle of the entity by finding the core business activities and extracting the core entity from an abstract point of view. May be a little bit around, the key words are: core business activities, core entities, core entity life cycle.

Take the live entertainment industry as an example, the following picture contains the whole life cycle of the business at the highest level of abstraction. I understand that the main body at this level of abstraction is tickets, the result of project production is tickets, distribution or e-commerce services are ticket sales, and the site is the verification of tickets, thus ending the life cycle with tickets as the core entity.

If we go down to the Down level, from the perspective of the business activity of project production, the whole business process is as follows:

Project Management-> venue seat Distribution-> Box Office Forecast-> performance Management-> quota Management-> drawing seat-> Box Office Planning

From the perspective of production, the core entity is not the ticket, but the number of events (a performance or event that determines the time, place and content), and all key business activities are based on the number of venues. The main thing to consider in the production field is the core life cycle of the event.

Therefore, in different abstract angles and different levels of abstraction, according to the different division of labor, there will be different core business activities, different core entities, the key to the determination of boundaries is to find the core life cycle. The process of looking for the life cycle is the process of discovering cohesion; accumulating all the business activities about the life cycle can enhance the cohesion of the domain or module.

4. Abstract assessment

Before that, we basically explained the angle, level and boundary of the abstraction, and determined the result of the abstraction from three dimensions. So how to evaluate the quality of abstract results? The answer is "high cohesion, low coupling". Of course, there are more principles, but from a practical point of view, I think this is the most important.

Coupling is a measure of the connection between modules in a software structure.

Cohesion is a measure of the degree of correlation between the components within a module.

"High cohesion, low coupling" evaluates abstract results from both internal and external perspectives. There are also corresponding principles and methodologies, and the conventional routines are:

Divide it from one angle at a time, and then look at the key points of view to refine and optimize the model and design (abstract results) through composition and split: coupling: reducing communication between modules; cohesion: functional homogenization; isolation of change: reducing information dependence, building isolation layer, virtual layer. 5. Abstract methodology (routine)

I think, at this point, we have made the first two questions clear:

In business modeling, "reading books" is classified and summarized, and "overall vision" is established to form a big picture. what dimension is it classified here? How to judge that the classification is correct?

How to remove "peeling onions" in system modeling? Press what? How are the levels and domains in the above architecture diagram divided? Where is the boundary?

Summarize all the content about abstraction mentioned above and form an abstract methodology (routine):

There are two ways of abstraction, one is top-down, the other is bottom-up

Business modeling is an abstract process of induction and deduction from small to large, from part to whole, and from bottom to top.

System modeling is an abstract process of disassembly and segmentation from big to small, from whole to part, from top to bottom.

But not absolutely, top-down and bottom-up are often switched at will in the process.

The following picture is from "Thinking in UML". I think the process of this cycle can express the above four points for your reference.

How to draw a good architecture diagram?

Back to the subject, if the above question is clear, the next thing will be relatively simple. For the question of what the architecture diagram is, we can extend the previous equation: architecture diagram = the expression of the architecture = the expression of the architecture at different abstract angles and levels of abstraction, which is a natural process. Instead of having diagrams followed by business processes, system design and domain models, on the contrary, diagrams are used to express abstract thinking and content.

So what's the use of architecture diagrams? To who? To answer this question, you need to explain clearly why you need easel composition, and you also need to consider a question: is the more architectural diagrams the better, the more detailed the better?

1. What is the easel composition for?

A picture is worth a thousand words (a picture is worth a thousand words), from the Why level, I think it is the following two points:

Solve communication barriers: reach consensus and reduce ambiguity

Improve collaboration efficiency: collaboration, communication, vision and guidance within and between teams.

But the above two points are actually very general information. If we put it at the What level, we must consider the "customers" faced by the architecture diagram. Different customers have different demands (that is, angles and levels), and the information content expressed by the architecture diagram at different levels of abstraction can be completely different. Taking what the team is doing as an example, there are at least several types of target customers for the architecture diagram:

Customers (external customers, external review experts) outside the project (business, product, development, testing, security, GOC) of all teams involved in the project (reporting, cross-BU, cross-team collaborative communication) at all levels.

So easel composition, we must first clear the purpose of communication and communication for customers, only a clear understanding of these two points can be more targeted to achieve the above two goals: to solve communication barriers and improve the efficiency of cooperation.

two。 How do you draw it? 1) Let's start with classification.

In essence, the classification of architecture diagram is to make a clear and simplified description from different perspectives and abstract angles, covering features and ignoring irrelevant aspects.

From the dimension of business application development, the general level of abstraction can be divided into:

Business global-> subdomain-> module-> submodule-> package-> class-> method

Among them:

Lower-level abstraction: apply internal package diagrams, class diagrams; a domain: entity diagrams, sequence diagrams, state diagrams, use case diagrams, etc.

High-level abstraction: with a certain degree of complexity, such as micro-service architecture, interaction diagrams between systems, domain / subdomain architecture diagrams, whole system architecture diagrams, and so on.

Of course, there are many other ways to classify, such as: RUP 419, magic GOGAF9, and so on. From a practical point of view, I think what kind of classification is not the most important, the most important thing is to figure out who to face and what demands to solve, and then think about the perspective and level from which the architecture diagram is abstracted. For the projects we are currently doing, we often have to communicate with foreign business experts and technical experts, and we do not have a clear standard definition, express the problem clearly, and reach a consensus, which is the most critical. As for the granularity, category, and content of the architecture diagram, it can be improved step by step, refined and optimized iteratively.

2) then talk about composition

In the part of composition, we have all used UML to draw class diagrams, involving generalization, aggregation, composition, dependency, and so on, which are expressed in different dotted lines and arrowheads. Therefore, the composition of the easel needs to consider the components of the architecture diagram, and to ensure consistent understanding, the components of the architecture diagram may involve:

Boxes, shapes, dotted lines, arrows, colors (what do different colors mean) and text content

What does the dotted line express? Component type, module type, layer, service, need to consider whether it has been implemented, etc.? How to pass the identification of different states?

What does the arrow mean? Data flow or relationship?

Interaction types can be synchronous or asynchronous; association types can refer to dependencies, inheritance, and implementation.

The most important thing in composition is to consider the consistency of content terms, fragmentation, the granularity of information, and the appearance of the chart.

3. How to judge the quality of the architecture diagram

I understand that the quality of the architecture diagram is mainly in two directions. One is to look beyond the diagram itself to see whether the abstract design of the business domain is reasonable and meets the requirements of "high cohesion and low coupling". This needs to go back to the previous business modeling, system modeling and abstract process to find the answer. The other direction is the diagram itself. The following points are for reference:

Consistent content terms, uniform information granularity, clear legend, uniform color type, and beautiful appearance.

The information in the diagram is relevant to the corresponding level of abstraction and meets the needs of stakeholders (partners).

A good architecture diagram does not need extra text explanation! Does the audience accurately receive the message they want to convey; if it causes more questions than it can explain, then it is not a good architectural picture.

The architecture diagram should help everyone see the big picture, understand the surrounding environment, and have appropriate contextual information.

The architecture map should avoid "seeing only the trees, not the forest".

However, after all, it is still the saying, "A picture is worth a thousand words." Whether it is good or bad, whether it is beautiful or not, people are visual animals, using picture expression can greatly improve the efficiency of communication, draw it first!

Finally, let's talk about the architect.

This is from teacher A Bai's article "what exactly does an architect do?" "the more you think about it, the more deeply you think about it. It mentions the portraits of good architects and bad portraits, such as the following picture, to share with you.

From my personal growth experience, it is important for architects to learn to "weigh" both the pain points of the moment and the development of a certain period of time in the future, to retain future scalability and to avoid overdesign. It is very important to choose what kind of time node, what kind of business scenario and what kind of architecture iteration strategy. The key to these decisions lies in judgment and trade-off, which needs to be combined with deep business thinking and even organizational structure to weigh the landing. A little bit of inexperienced experience:

1. Fast learning

Speed is not a question of speed, but also a matter of judgment or standard. In the face of a new business scenario, how to identify 20% of the critical business paths, key business pain points, and how to turn yourself into a business expert in a short time is the basic quality of an architect. One of my experiences is to think actively with questions. Who is the customer? What do you want? What kind of problems need to be solved? What kind of value can we offer? Ask why? This also requires a long time of deliberate training.

two。 Don't decide your head with your ass.

To look at business issues across roles and levels, this point is easy to fall into preaching, and to be honest, I may not have done it myself. But always remind yourself of whether your thinking is limited, in which dimension, Have-do-be or be-do-Have, etc., and constantly remind yourself that you should never decide your head with your ass.

3. Improve the ability to think and understand the principle or nature of technology

I think this is the lowest level of ability, I think the two biggest difficulties in business development: one is the complexity of logic, the other is the variability of requirements. We should not spend most of our time finding solutions, but should spend more time choosing solutions. This requires us to form our own understanding of the overall business, industry depth, technology vision, technology depth, business commonness, personality characteristics and so on. Weigh the trade-off, choose what? How to choose how to give up? Where is that degree? Only thinking, self-driving, accumulation and persistence, brave and diligent, volunteer tirelessly.

The last.

I hope this article will be helpful to you and attach the conceptual process and thinking path when you first considered this topic for your reference.

Reference documentation: why do we need architecture diagrams (the art of https://new.qq.com/omn/20190131/20190131A16MWK.html) software architecture diagrams (https://www.infoq.cn/article/crafting-architectural-diagrams) logical architecture and physical architecture) https://www.cnblogs.com/dinglang/p/4565378.html) an article on understanding hierarchical architecture (https://zhuanlan.zhihu.com/p/40353581)TOGAF & RUP (how does https://www.ibm.com/developerworks/cn/rational/rationaledge/content/feb07/temnenco/index.html) derive the application logic architecture from the bottom up? + how to build an architecture from top to bottom? (excerpt) (https://developer.aliyun.com/article/727436) "Elephant: Thinking in UML"talk about Architecture"

Follow the official account of "Alibaba Cloud Origin" and reply to "structure" to see a clear knowledge picture!

Course recommendation

In order that more developers can enjoy the dividends brought by Serverless, this time, we have gathered 10 + technical experts in Alibaba's Serverless field to create an open Serverless course that is most suitable for developers to get started, so that you can easily embrace the new paradigm of cloud computing-Serverless.

Click to watch the course for free: https://developer.aliyun.com/learning/roadmap/serverless

"Alibaba Cloud Native focus on micro services, Serverless, containers, Service Mesh and other technology areas, focus on cloud native popular technology trends, cloud native large-scale landing practice, to be the official account of cloud native developers."

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.