The author | flute Ali recreational senior technical experts

Pay attention to the “Alibaba Cloud native” public account, reply to the structure can view a clear knowledge picture!

** What is the architecture diagram? Why an easel? How to draw a good architecture diagram? What are the methods? Starting from the definition of architecture, this paper shares the experience of Xiao Yi, senior technical expert of Ali Cultural Entertainment, on easel composition for many years, and discusses the concept of abstraction in depth. The content is long, students can collect up to read carefully.

What is an architecture diagram?

How to draw a good architecture diagram, to do this thing, the first answer is what is the architecture diagram. We often see a variety of architecture diagrams in our daily work, and often find that people have different understandings of architecture diagrams. It may be difficult to come up with a concrete definition at once, but it is easier to understand the problem if we break it down.

Architecture diagram = Architecture + DiagramCopy the code

Using this equation, we can change the question:

• What is the architecture?
• What is the picture?

What is the picture? This one is easy to answer. Diagrams are a way of expressing information, so an architecture diagram, a diagram that expresses “architecture”, is also an architectural representation. That is: Architecture diagram = expression of architecture = diagram expressing architecture.

Along these lines we need to answer:

• What is architecture? What is it?
• How to draw a good architecture diagram?

What follows is basically an analysis of these two dimensions.

What is architecture? What is it?

Linus had a good description in 2003 when he talked about 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. Breaking a complex system into modules does not seem to reduce the overall complexity of the system. All it does is reduce subsystem complexity. Instead, the complexity of the whole system will become more complicated because the split modules have to interact with each other.

I understand that the splitting of the system described here is an architectural process, with the basic starting point being efficiency, and the ultimate goal being to maximize efficiency through the proper splitting of the architecture, either spatially or temporally. There is no uniform and clear definition of what an architecture is. The following three definitions can be referenced.

Definition on Baidu Encyclopedia:

Architecture, also known as software architecture, is an abstract description of the overall structure and components of software used to guide the design of various aspects of large software systems.

Definition on Wikipedia:

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

ISO/IEC 42010:20072 defines architecture 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 are different, but we can basically conclude that architecture represents the overall structure and the relationship between components.

1. The nature of architecture

Here are three ideas 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 architecture is the systematic refactoring of systems to match current business developments and to scale quickly.

The three ideas mentioned above basically express the core purpose of architecture: to manage complexity and maximize efficiency. And two main sources of change in the architecture: one is inherent structural change to improve software quality; The other is a change in external functionality to meet customer needs.

No matter what kind of changes, in my opinion, architecture is constantly making judgments and trade-offs, making trade-offs between business requirements and system implementation, so as to cope with the uncertainty of future changes. The following figure can express this understanding in a superficial and intuitive way.

2. What is the message?

In the EA architecture field, there are two common architectural approaches, RUP and TOGAF, and these frameworks are two of the dimensions that we often learn about architecture classification. From a personal perspective, I myself think the TOGAF classification is more widely used (pictured below).

In combination with daily business development, we actually focus more on business architecture and application architecture, so we further disassemble the above expression. Before answering how to draw a good architecture diagram, we need to focus on business architecture and system architecture, and discuss clearly how to carry out business architecture and system architecture.

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

We all know that the transition from the real world to the software world, or the object-oriented world, is a process of constant abstraction, and the way to do that is through constant modeling. 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 the continuous abstraction to remove the rough, form layers of abstraction to the real world, so the process of architecture is actually a modeling process. At this point, it’s important to understand what modeling is.

Baidu Encyclopedia definition:

Modeling is to build a model, is to make an abstraction of things in order to understand things, is an unambiguous written description of things.

Definition in Thinking in UML:

Modeling refers to the establishment of an abstract method to represent the objective things and obtain an understanding of the things themselves. At the same time, this understanding is conceptualized and these logical concepts are organized to form an easy to understand expression of the internal structure and working principle of the observed objects.

From the above two definitions can learn basic modeling is to abstract, for business or abstraction of real world, though not enough to help us to understand the architecture itself, but we can be the focus of business architecture and system architecture is further Down the Down a layer, the process of architecture is the process of modeling, we converted into two simple questions: what is mold? How to build?

4. What is a module? How to build?

These are two questions that are easy to get bogged down in theory, so let’s jump out and see the process in terms of results. The next step is to answer these two questions by looking backwards at how the architectural diagrams were produced by looking at some of the architectural diagrams that have been produced.

1) Business modeling

Back to the current business itself, it is also brand-new for me. At the first contact, I understood with the only industry background and read a lot of documents, and finally produced the Business Core Flowchart and Business Function Module Diagram as shown below. These two charts basically cover all the business. The business flow chart on the left is recognized by an expert who has been in the industry for more than 20 years and says this is what the business is about.

The picture originates from the network, is schematic diagram, encroachment deletes

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

• “Read the book thick” : a lot of information input, while exploring possibilities;
• “Read the book” : classify and summarize, form a big picture;
• Logical comparison to ensure the correctness of understanding and analysis.

Read the book thick:

The following figure basically covers the process of “making the book thick”, gathering a large amount of document information and trying to form logic with multidimensional dimensions. This dimension may be based on historical experience or document content. For example, in the process of forming a large business picture, I have classified the contents of multiple documents according to possible scenario logic, possible system or domain logic to explore the possibility.

This process can be tedious, especially when it comes to business terminology, which can be difficult to understand. My approach is to think of myself as an “explorer,” as we do in games, asking ourselves “Is my map fully lit?” Don’t necessarily cover all the details, but try to cover the whole picture. If you think about it, it seems to be similar to everyday reading, but it’s worth noting that:

• Focus on where some of the business concepts are defined and where their logic is not in line with their own reasoning;

• Constantly adjust the dimensions recorded in my reading process and correct my analysis direction;

• Old honesty in practical documents to record and present the original words (this is very important, especially reading English materials, the best original record, help to improve their professional).

Read a book:

This time the key is to build a “big picture”, try to comb their logical mainline, conventional logic will be divided into horizontal and longitudinal, or matrix framework, and of course it needs to be built on understanding and analysis of early, often implied here * * the most important assumption: the system must be used to people, must be to solve the problems of the customer, otherwise there is no the meaning of existence. So the core formula is: Who? What services/functions/capabilities are used? What kind of problems? Thus characterizing: actors’ roles, system capabilities, interactions, the question to ask yourself is: What are the boundaries? What are the inputs and outputs? ** Gradually tease out business functions through use cases to form roles — > main processes — > branch processes, and then form the final abstract business description “a map” through continuous induction and deduction.

A small detail is not to try to quickly complete the drawing of the big picture in the brain through these processes, or need to start from small links, a part of the small business closed loop into a small block, do not let it occupy the brain space, and then gradually overall thinking and grasp, gradually form a big picture; At the same time, the style of the big picture is completely ignored, and then the logic is carefully adjusted. Emphasize this detail, because attempt to “picture” to describe a very large business itself is a very challenging thing, if you don’t do so easy to let oneself become anxious and irritable, it is a slow process, need patience, need to slow down, where the key block even repeated again and again to complete the final.

Logical comparison:

This is a closed loop encapsulation process, the previous record in the process of “read” thick, some logic details, key process to go one by one into the larger image contrast verification, to ensure the integrity of business understanding and accuracy, and ensure that business abstract can cover all known business use cases, even to support the business scenario to may. This part is also essential.

To sum up business modeling (as shown in the figure below), through the above three main processes, we can basically produce some big diagrams, block diagrams, flow charts, use case diagrams, etc., of the business architecture. What kind of diagrams is not important, but who is the diagram facing? What is it mainly used for? And I’ll talk about angles later on. From our current business scenario, the core purpose of a business architecture diagram is to build consensus and reduce the cost of communication, so that everyone can say the same thing and describe the same thing, regardless of the role in the project. This is to establish the 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 professional, on the other hand, the ability to talk to customers is more important, this is why the above mentioned in the original text as far as possible to present the purpose of a picture.

2) System modeling

Business modeling completes the construction from the real world to the business model. On this basis, how to complete the mapping from the business model to the design model through abstraction is the problem to be solved by the system modeling. From the perspective of research and development, a variety of model diagrams will be produced at this stage, such as entity model diagram, timing diagram, state diagram, architecture diagram of each level, etc. However, no matter what perspective and level, system modeling must be based on business modeling to complete the mapping between business requirements and system models. This involves mapping business functions to system capabilities and business processes to data processes; System modeling emphasizes responsibilities, dependencies and constraints, and is used to guide the implementation of r&d.

Aside from the specific sequence diagram and state diagram, let’s take a look at the following architecture diagram in several dimensions:

The picture originates from the network, is schematic diagram, encroachment deletes

The above images are different in perspective, level, and user facing. Basically, you can see the whole picture, but with different levels of detail and different emphasis on information. So how to do it when modeling a system, I often use this method (not always) :

• “Peeling the onion” from large to small, from coarse to fine, covering all known and possible future business scenarios; Good at using various model representations: natural language, relational model, sequence diagram, state diagram, flow diagram, various hierarchical architecture diagrams, etc., to fully express various business scenarios and constantly verify;

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

• The ultimate weapon: all the design/logic fuzzy points, put all the known scenarios separately and tell them to yourself.

“Peeling an onion” :

Peel the onion based on the results of the business modeling. It’s a continuous process of disassembly, and one of the most important ways of disassembly in this process is by dividing the system. How to divide the labor? Which module is responsible for what? What are the inputs and outputs of the module? What services and capabilities are provided internally? These questions are answered in the abstract part of the following text. In a word, “peeling the onion” means that from the “big picture” of business modeling, it can be broken down into multiple subsystems and sub-modules according to the division of responsibilities, and then the modules can be subdivided and stripped layer by layer.

Core entity extraction:

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

• Object analysis method

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

From this concept understanding, and our object-oriented everything and object understanding is basically the same. Therefore, the extraction of entities can also draw lessons from the methods of object analysis: independent, abstract, hierarchical, and atomic in a single level. The following figure shows the analysis method for objects in Thinking in UML.

• Methods of use case analysis

By extracting keywords from business use cases, different keywords may express entities, relationships, attributes, etc., thus completing model analysis and building. Here is a brief introduction to the basic Abstract Method of Problem Space Domain Model by Teacher Liu Baht:

In a complete use case description, first find the nouns, mainly “subject” and “object”, which basically identify our entities; Secondly, find adjectives, which exist in “attributive” and “adverbial”, and find adjectives can basically determine the value of the corresponding attribute; Then by supplementing and refining the use cases and defining the nouns, we will gradually get our domain model and corresponding attributes. Finally, the relationship between them is determined by the verb & adjective (exist in, exist in, exist in).

• Method of problem analysis

This is the way mentioned in “Chat Structure”. Specifically, it is to find the subject of the problem, then analyze the life cycle of the subject, and then focus on the key attributes and key relationships of the subject by distinguishing the key activities in the life cycle. I recommend reading the first nine chapters, which are only 40 pages in total, so you’ll get a sense of it. Here’s an example from the book:

A joke: a lady said to her husband: peel half of the potatoes in the bag into the pot; All the potatoes were in the pot, and each potato was half peeled.

The author points out that there is no clear set of subject here. The subject is not just a potato, but an implied person who wants to eat potatoes. The relationship between the two entities is the business scenario to be solved: how to eat? How to eat? Why? Therefore, unclear identification of the subject may lead to deviation of the overall implementation. Of course, the actual process does not make such a stupid mistake, but it also shows that the extraction of core entities is very critical.

The ultimate weapon – Tell yourself:

In actual business development, a business design implementation often needs to meet N upper-level business scenarios, which have commonalities and personalized demands. In this process, we are easily confused by the similarities and differences between multiple scenarios, or the logic is not clear, or the over-design, or the ill-considered. I have observed that many students, including myself, tend to lose the focus of design in certain business complexity. My approach is similar to that of business modeling, where there must be a logical contrast: at all design/logical fuzzy points, put all known scenarios separately and tell them to yourself. Please note that this is “separately embedded”. Verify the next scene after verifying the next scene at the current design level, find out the blocked and fuzzy points, and then rearrange and optimize the design. The results of system modeling guide our software design and implementation, so we must repeatedly tease out and get through. This repeated process is actually a process of improving the architectural capability, and it will be naturally transparent when accumulated to a certain extent.

Back to the original question:

What is ** module? ** From the description of business modeling and system modeling above, a module is simply a mapping of a business. The result of this mapping is a business model, a conceptual model, or a design model, but all starting from a business requirement: who is the customer? What is the core appeal?

** How to build? ** The above two dimensions of business modeling and system modeling, from the perspective of personal practice about the general routine, the essence of modeling is actually an abstract process, but the above business and system modeling abstract process in fact, there are two problems are not fully clear:

• In business modeling, “reading books” are classified and summarized, and “big picture” is established to form a big picture. What dimensions are classified here? How to judge the classification is correct?

• How to dismantle the “peeling onion” in system modeling? Press what? How are the layers and domains in the above architecture diagram divided into layers? Where is the border?

Back to the abstract

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

**”abstraction, abstraction, abstraction”**are the three most important things in programming.

If you ask a programmer what are the most important capabilities, I believe abstraction must be one of the most important. So what exactly is abstraction?

Baidu Encyclopedia definition:

Abstraction is a process of thinking that extracts and generalizes the common aspects, essential attributes and relations of concrete things, while discarding the individual and non-essential aspects, attributes and relations.

If a more concise generalization: abstraction is subtraction and division. By discarding the non-essential and irrelevant parts, we focus on the essence of the problem and get rid of the rough and the fine; By looking at the essence through the phenomenon, we can find the common points between different things, seek the same from the different, and merge the same with the same, which is to do division. The modeling process mentioned above is a common abstraction. Until a certain state is reached through continuous abstraction, I understand that there is no deterministic answer to this state, and the core is to meet the needs of business scenarios. In fact, there is a boundary problem behind this.

1. Abstract perspective

Life is full of abstractions, but we seem to lack the thought of why it is this or that. Abstractions have angles.

In life, we often say, “My opinion is that… In fact, the “point of view” here is a point of view, from a certain standpoint or perspective, the view of things or problems. Take the common objects in life (below), can we quickly tell the similarities and differences among them?

Have marked as shown in figure, we from the Angle of function, they define the chairs, tables, stools and cabinet this distinction, but obviously there are many, many angles, such as: material, dimensions, height, etc., from the different dimensions in the past, there will be a completely different the similarities and differences of expression, so, what is nature? Nature is:

• Abstract Angle is also the Angle of classification, different Angle, will lead to completely different modeling direction and results;

• The abstract Angle is the direction and purpose of modeling (” the ass determines the head “).

Going back to our previous two questions, in business modeling we talked about categorization, categorization by what, the answer came out, categorization by our business process, categorization by the role of the customer, back to the original question: who is the customer? What is the core appeal?

At the same time, as mentioned above, modules are business mappings, and based on our understanding of abstractions, we can further expand: modules are business mappings in terms of determining abstractions.

2. Levels of abstraction

Wikipedia’s definition of abstraction has an example of a newspaper:

1. My May 18th San Francisco Chronicle
2. San Francisco Chronicle, May 18
3. San Francisco Chronicle
4. A newspaper
5. A publication

In these five sentences, we can feel the level of abstraction, the higher the level of abstraction, the less detail, the more universal. Another example is the abstraction of the network model in the figure below, and the abstraction of the operating system kernel. We can clearly see that different levels of abstraction filter different information, and the information left is the information needed for the current level of abstraction. In terms of system design and implementation, the higher the level of abstraction, the closer it is to the design and the farther away it is from the implementation. Meanwhile, the more the abstract model is not hindered by details, the higher the stability, the stronger the universality and the higher the reusability.

So what is the basis for the level of abstraction here? What are the principles? My experience is that there are two main ways to divide levels of abstraction:

• Layering in abstract terms (one layer may be the aggregation of multiple perspectives)
• Layering in the face of change (isolating change with layers)

This doesn’t really explain how to layer it. What’s the principle? I think these are some of the most general principles:

• Public go down
• Personality goes up
• The lower layer can exist independently of the upper layer
• Control changes in the lower layers

The good thing about thinking about levels of abstraction is that we only have to deal with a limited amount of complexity at any level, so we can focus on what the abstraction is at that level and what the information is.

3. Abstract boundaries

In addition to angles and levels, we also need to consider the boundaries of abstraction. If the level considers the expression of the vertical dimension, the boundary considers the expression of the horizontal dimension. How to define boundaries, ** a general principle is to divide the boundaries according to responsibilities, which in this case are just divisions of labor. ** Once the responsibilities are determined, we do not need to put the whole business into the analysis from beginning to end when doing modeling analysis, we only need to consider the upstream and downstream under the current division of labor, so the amount of information is greatly reduced, and naturally the domain complexity we face will be reduced to a certain extent.

If the definition of boundary must be given, my understanding is that the boundary is the result of further determining the core life cycle of the entity by searching for core business activities and extracting core entities in the abstract perspective of determination. The key words are: Core business activity, core entity, core entity lifecycle.

With live entertainment industry as an example, the following this picture contains the highest level of abstraction of whole life cycle of the business, what is the main body of below this level of abstraction, my understanding is, production as a result of the vote, distribution or electric service is for ticket sales, the scene is the check for tickets, tickets so far as the end of the life cycle of the core entities.

If we go Down one level and look at the business activity of project production, the whole business process looks like this:

Project management -> venue seat distribution -> box office forecast -> time management -> quota management -> seat drawing -> box office planningCopy the code

From the perspective of production, the core entity is not ticket, but event (a performance or event with fixed time, location and content). All key business activities take event as dimension, and the core life cycle of event is the main consideration in the production field.

Therefore, at different abstract angles and levels, there will be different core business activities and core entities according to the different division of labor. The key to determine the boundary is to find the core life cycle. The process of finding a life cycle is the process of finding cohesion; The accumulation of all the business activities related to the lifecycle improves the cohesion of the domain or module.

4. Abstract assessments

In the previous section, we basically clarified the Angle, level and boundary of abstraction, and determined the results of abstraction from three dimensions. So how do you evaluate the results of abstraction? The answer is “high cohesion, low coupling.” There are more principles, but from a practical point of view, I think this is the most important.

· Coupling is a measure of the interconnections between modules in a software structure; · Cohesion is a measure of the degree to which the components within a module are related to each other.

“High cohesion, low coupling” evaluates abstract results from both internal and external perspectives. There are principles and methodologies, and the general formula is:

• Do it from one Angle at a time, and then look at it from multiple angles
• Refine and optimize models and designs by combining and splitting (results of abstraction)
• Key points to look at: Coupling: reduced traffic between modules; Cohesiveness: simplicity of function; Change isolation: reduce information dependence, build isolation layer, virtual layer.

5. Abstract Methodology (routine)

Now, I think we’ve cleared up the first two questions:

• In business modeling, “reading books” are classified and summarized, and “big picture” is established to form a big picture. What dimensions are classified here? How to judge the classification is correct?

• How to dismantle the “peeling onion” in system modeling? Press what? How are the layers and domains in the above architecture diagram divided into layers? Where is the border?

To sum up all that has been said about abstraction and form the methodology (routine) of abstraction:

• There are two ways to abstract, 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, from bottom up;

• System modeling is an abstract process from large to small, from whole to part, from top to bottom;

• But not absolutely, top-down and bottom-up, often in the process is arbitrary switch.

The figure below is from Thinking in UML, and 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 point, if the above questions are clear, the rest of the story is relatively simple. For the question of what an architecture diagram is, we can extend the equation: ** Architecture diagram = representation of the architecture = representation of the architecture at different levels of abstraction, and this is a natural process. ** Instead of having diagrams before business processes, system designs, domain models, etc., instead, use diagrams to express abstract thinking and content.

So what is the use of an architecture diagram? To give who see? To answer this question, we need to explain why we use easels for composition, and we also need to consider the question: is the more and 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.

• Solve communication barriers: reach consensus and reduce ambiguity;

• Improve collaboration: collaboration, communication, vision and guidance within and across teams.

However, the above two points are actually very general information. At the “What” level, we must consider the “customers” facing the architecture diagram. Different customers have different demands (in fact, the Angle and level), and the information content expressed by the architecture diagram can be completely different at different levels of abstraction. As an example of what the team is currently doing, there are at least a few types of target customers for architecture diagrams:

• Each role (business, product, development, test, security, GOC) of each team involved in the project
• Clients outside the project (external clients, external review experts)
• TL at all levels (reporting, cross-BU, cross-team collaboration and communication)

Therefore, as for easel composition, we must first clarify the purpose of communication and the target customers. Only by clarifying these two points can we achieve the two goals mentioned above in a more targeted way: to solve communication barriers and improve collaboration efficiency.

2. How to draw?

1) Classification first

Architecture diagram categorization, essentially, takes a different perspective, a different abstract perspective, and creates a clear, simplified description that covers features and ignores irrelevant aspects.

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

Service Domain - > Subdomain - > Module - > Submodule - > Package - > Class - > MethodCopy the code

This among them:

• Lower levels of abstraction: application internals, class diagrams; A domain: entity diagram, timing diagram, state diagram, use case diagram, etc.

• Higher levels of abstraction: have some complexity, such as microservice architecture, interaction diagrams between systems, domain/subdomain architecture diagrams, overall system architecture diagrams, etc.

Of course, there are many other categories, such as RUP 4+1, 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 should be abstracted. * * we do project at present, there is a time to go abroad and the business experts, technical experts to communicate, you also doesn’t have a clear standard definition, clearly stated, reached a consensus that is the most crucial, as for the architecture diagram of particle size, category, content can be gradually to perfect, pursuit, the iterative optimization.

2) Composition

For the composition part, we have all drawn class diagrams in UML, involving generalization, aggregation, composition, dependency, etc., and expressed with different virtual and solid lines and arrow styles respectively. Therefore, the composition of an easel needs to consider the elements of an architectural diagram to ensure consistent understanding. Elements of an architectural diagram may include:

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

• What do dotted and solid lines say? Component type, module type, layer, service, need to consider whether it has been implemented etc.? How are the different state identifiers passed?

• What does the arrow say? Data flow or association?

• The interaction type can be synchronous or asynchronous; Association types can refer to dependencies, inheritance, and implementations.

The most important aspects of composition are the consistency of content terms, fragmentation, granularity of information, and the appearance of the diagram.

3. How to judge the quality of an architecture diagram

I understand that the quality of an 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 be answered by going back to the previous business modeling, system modeling and abstract process. The other direction is the graph itself. The following points are for your reference:

• The content term is consistent, the granularity of information is consistent, the legend is clear, the color type is unified, beautiful;

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

• A good architecture diagram does not need redundant text explanation! Whether the audience has accurately received the intended message; If it raises more questions than it explains, then it’s not a good architecture diagram;

• Architecture diagrams should help everyone see the big picture, understand the environment around them, and contextualise information appropriately;

• Architecture diagrams should avoid “missing the forest for the trees”.

But, after all, “a picture is worth a thousand words”. Whether it is good or bad, whether it is beautiful or not, people are visual animals, using pictures to express can greatly improve the efficiency of communication, draw up first!

Finally, architects

This is from Teacher Bai’s article “What does an Architect actually do?” The more I think about it, the more I think about it. It mentions the portrait of a good architect and the portrait of a bad architect.

From my personal experience, it is very important for architects to learn the “tradeoff” between the current pain points and the future, while preserving the future extensibility and avoiding overdesign. What kind of time node, what kind of business scenario and what kind of architecture iteration strategy to choose are crucial. The key to these decisions lies in judgment and trade-offs, which need to be combined with deep business thinking and organizational structure to make trade-offs. ** A little experience is not experience:

1. Learn quickly

Fast is not a matter of speed, but also a matter of judgment or standard. Facing a new business scenario, how to identify 20% of the critical business path, critical business pain points, how to turn yourself into a business expert in a short period of time are the basic qualities of an architect. One of the lessons I’ve learned is to think in a “monetized” way, with the question, who is the customer? What are the demands? What problems need to be solved? What kind of value can we provide? Ask why? It also takes long hours of deliberate training.

2. Don’t make your head out of your ass

It’s easy to get moralistic about looking at business issues across roles and levels, and to be honest I don’t always do that well myself. But always remind yourself whether the thinking is limited, which dimension, whether it is have-do-be, be-do-have and so on; At the same time, I constantly remind myself that my head should never be determined by my butt.

3. Improve your thinking and understanding of the principles or nature of technology

In my opinion, this is the lowest level of capability. In business development, I think the two biggest difficulties are the complexity of logic and the variability of requirements. We shouldn’t spend most of our time looking for solutions, we should spend more time choosing solutions. This requires us to form our own cognition of the overall business, industry depth, technical vision, technical depth, business commonness, personality characteristics and so on. What’s the trade-off? What’s the trade-off? What should I do? Where is that degree? Only thinking, self-drive, accumulation and persistence, indomitable and vigorous, unwearied.

At the end

I hope this article will be helpful to you. Attached is my initial thinking process and thinking path when considering this topic for your reference.

Reference documents:

• Why we need architecture diagrams (new.qq.com/omn/2019013…)
• The Art of Software Architecture Diagrams (www.infoq.cn/article/cra…)
• The logical architecture and physical architecture (www.cnblogs.com/dinglang/p/.)
• Read an article layered architecture (zhuanlan.zhihu.com/p/40353581)
• Other & RUP (www.ibm.com/developerwo.)
• How to derive the application logic architecture from the bottom up? + How to build an architecture from the top down? (excerpts) (developer.aliyun.com/article/727…).
• Elephant: Thinking in UML
• Talk about Architecture

Pay attention to the “Alibaba Cloud Native” public account, reply to “architecture” to view a clear knowledge picture!

Course recommended

In order for more developers to enjoy the dividends brought by Serverless, this time, we have assembled 10+ Technology experts in the field of Alibaba Serverless to create the most suitable Serverless open class for developers to learn and use. Easily embrace the new paradigm of cloud computing – Serverless.

Click to free courses: developer.aliyun.com/learning/ro…

“Alibaba Cloud Primitive focuses on micro-service, Serverless, container, Service Mesh and other technical fields, focuses on cloud native popular technology trends, cloud native large-scale practice, and does the public account of cloud native developers who understand the most.”