How to draw a good architecture diagram?

Posted Jun 15, 202024 min read

Introduction:What is the architecture diagram? Why draw an architecture diagram? How to draw? What are the methods? This article begins with the definition of architecture, shares the experience summary of Alibaba Entertainment senior technical expert Xiao Yi on drawing architecture diagrams for many years, and discusses the concept of abstraction in depth. Longer, students can read it after collecting.


What is an architecture diagram?

How to draw an architecture diagram, the first thing to be answered is what is the architecture diagram. In our daily work, we can often see a variety of architecture diagrams, and we often find that everyone has their own understanding of the architecture diagram. Investigating this problem in depth, it may be difficult to have a concrete definition at once. If we split this problem(as shown below), it will be easier to understand.

Architecture diagram = architecture + diagram

According to this equation, we can convert the problem:

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

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

Architecture diagram = expression of architecture = diagram representing architecture

Following this line of thought we need to answer:

  • What is architecture? What is it to express?
  • How to draw an architecture diagram?

The following content is basically based on these two dimensions for analysis.

What is architecture? What is it to express?

Linus had a good description when talking about splitting and integration in 2003:

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 us recognize a phenomenon that splitting a complex system into modules does not seem to reduce the complexity of the entire system. It only reduces the complexity of the subsystem. And the complexity of the entire system is actually due to the split The modules have to interact with each other and become more complicated.)

I understand that the system split described here is the process of architecture. The basic starting point is for efficiency. Through the rational split of architecture(whether it is a split in space or time), the ultimate goal is to maximize efficiency. In the end, what is architecture is actually not completely unified and clear definition, the following three definitions can refer to.

Definition on Baidu Encyclopedia:

Architecture, also known as software architecture, is an abstract description about the overall structure and components of software, and is used to guide the design of all aspects of large-scale 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 the 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 also different, but we can basically conclude that the architecture reflects the relationship between the overall structure and components.

The essence of architecture

Three points are cited here to explore the essence of architecture:

  • The essence of the architecture is to manage complexity.
  • The essence of architecture is to orderly reconstruct the system, continuously reduce the "entropy" of the system, and make the system evolve continuously.
  • The essence of the architecture is to restructure the system in an orderly manner to conform to the current business development and can be rapidly expanded.

The content mentioned in the above three views basically expresses the core purpose of the architecture:management complexity and maximum efficiency. And the two main sources of changes in the architecture:one is the internal structural changes for the purpose of improving software quality; the other is the external functional changes for the purpose of meeting customer needs. No matter what kind of change, in my opinion, the architecture is constantly judging and choosing, making trade-offs between business needs and system implementation, in order to cope with the uncertainty of future changes. The following figure can express this more superficially and intuitively. Kind of understanding.


What do you want to express?

In the field of EA architecture, there are two common architectural methods RUP and TOGAF, these two frameworks are also two dimensions that we often understand the classification of architecture. From a personal point of view, I feel that TOGAF's classification is more widely used(pictured below right).


Combined with daily business development, in fact, we are more concerned about the business architecture and application architecture, so the above expression is further dismantled. Before answering how to draw an architecture diagram, we need to pay attention to the business architecture and system architecture. Discuss how to conduct business architecture and system architecture.


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, and the method in this 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 to roughen and refine to form a layered abstraction of the real world, so the process of architecture is actually the process of modeling. At this point, we need to understand what modeling is.

Baidu Encyclopedia definition:

Modeling is to build a model, which is an abstraction made to understand things, and is an unambiguous written description of things.

"Thinking in UML" defines:

Modeling(Modeling) refers to establishing an abstract method for objective things to characterize things and gain an understanding of the things themselves, while conceptualizing this understanding and organizing these logical concepts to form a 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 abstract. Although the abstraction of the business or the real world is not enough to help us understand the architecture itself, it can further down the business architecture and system architecture that we focused on above. The process of architecture is the process of modeling. We converted into two simple questions:what is the model? How to build?

What is a die? How to build?

These are two problems that are more likely to fall into theory, and we jump out and look at the process from the results. Next, look at how these architecture diagrams are produced in reverse through some of the architecture diagrams that have been produced, and answer these two questions at the same time.


Business modeling

Returning to the current business itself, it is also brand new to me. At the time of initial contact, I understood it with the only industry background, combined with a lot of document reading, and finally produced the "Business Core Flowchart" and "Business Core Flowchart" as shown below Business function module diagram". These two pictures basically cover all the business content. The business flowchart on the left has been recognized by experts in this industry with more than 20 years of experience. He believes that this is the content of the business that he has been engaged in for more than 20 years.


Looking back at the entire process, especially the business core flowchart on the left, today we see this flowchart is very easy to construct a basic logic, vertical is different business roles and systems, horizontal is the advancement of time, especially 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 used in this process is:

  • "Read the book thick":a large amount of information is input, and the possibility is explored at the same time.
  • "Read the book":group and summarize to form a big picture.
  • Logical comparison to ensure the correctness of understanding and analysis.

1) Read the book thick

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

This process will be very boring, especially when it comes to some business terms, it will be difficult to understand. My way is to think of myself as an "explorer." Like we play games, I often ask myself "Is my game map all lit up?" It is not necessary to take care of all the details, but it needs to strive to cover the entire content. If you think about it carefully, it seems to be similar to daily reading. During this period, it is worth noting that:

  • Focus on places where some business concepts are defined, and where there are discrepancies with your own logical reasoning.
  • Constantly adjust the dimensions recorded in your reading process, correct your analysis direction.
  • To record and present the original words in the honest and practical documents(this is very important, especially when reading English materials, the best original records are helpful to improve your professionalism).


2) Read the book

The focus at this time is to establish a "big picture" and try to sort out the main logic of the logic. Generally speaking, it will be divided into horizontal and vertical, or matrix frameworks. Of course, this needs to be built on previous understanding and analysis. It is often implied here. One of the most important assumptions:the system must be used by people, it must solve customer problems, otherwise there is no meaning. So the core routine is:who? What services/functions/capabilities are used? What kind of problems are solved? In order to portray:participant roles, system capabilities, and interactions, you often need to ask yourself:What is the boundary? What is input and output? Gradually use cases to sort out business functions and form roles >main process >branch process, and then form the final business abstract description a picture through continuous induction and deduction.

A small detail is not to attempt to complete the drawing of the big picture in the brain quickly through these processes, or do we need to start from the small link and make some small business closed loops into small groups of blocks, do not let it occupy the space of the brain Then, gradually think and grasp the whole, and gradually form the big picture; at the same time, the style of the big picture is completely ignored first, and the logic is then adjusted carefully. The reason for emphasizing this detail is because trying to describe a very large business through "a picture" is a very challenging thing in itself. If you don't do this, you will easily make yourself anxious and irritable. This is a slow effort. It takes patience, you need to slow down in the place where the key is blocked, and even repeat it over and over again to finally complete.


3) Logical comparison

This is a closed-loop encapsulation process. The logic details and key processes of the previous "reading thick" process must be put into the big picture one by one for comparison and verification to ensure the completeness and accuracy of business understanding and ensure business abstraction. It can cover all known business use cases and even support possible business scenarios. This link is also an essential part.

Summarizing business modeling(see the following figure), through the above three main processes, we can basically produce some big diagrams, block diagrams, flowcharts, use case diagrams, etc. of the business architecture. What kind of diagram is not important, important Who is this picture facing? What is it used for? I will also talk about drawing angles later. From our current business scenarios, 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 the establishment of 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 to communicate with customers is more important. This is why we mentioned above. Use original text as much as possible to present the purpose of a picture.


System Modeling

Through the business modeling, the construction from the real world to the business model is completed. On this basis, how to complete the mapping of the business model to the design model through abstraction is a problem to be solved by system modeling. From the perspective of R&D and implementation, a variety of model diagrams will be produced at this stage, such as physical model diagrams, timing diagrams, state diagrams, architecture diagrams at various levels, etc., but no matter what angle or level, the system is built The model must be based on business modeling to complete the mapping between business requirements and system models; this involves the mapping of business functions to system capabilities, business processes to data processes; system modeling emphasizes responsibility, dependencies, and constraints , Used to guide the implementation of R&D.

Putting aside the specific timing diagrams and state diagrams, let's take a brief look at the architecture diagrams in the following dimensions:


The perspectives, levels, and user orientations of the above pictures are different, and basically you can see the whole, but the level of detail is different, and the information focused on is also completely different. So what should I do when modeling the system, the method I often use in this process is(not exactly):

  • "Onion peeling" from large to small, from thick to thin, covering all known and possible future business scenarios; good at using various models to express:natural language, relationship model, sequence diagram, state diagram, flow chart, various Various hierarchical architecture diagrams, etc. are used for model expression, fully expressing various business scenarios and constantly verifying.
  • Extraction of core entities:Grasp the core concepts and the core relationship to complete the establishment of the core model.
  • Ultimate Weapon:All the points of design/logic ambiguity, set all the known scenes separately, and talk to yourself.

1) "Peeling Onions"

Based on business modeling results, "peeling onions" is carried out. This is a process of continuous dismantling, and a very important way of dismantling in this process is to divide the system. How to divide the work? 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 later in the abstract section. In one sentence, "peeling onions" is:from the "big picture" of business modeling to dismantling into multiple subsystems and multiple sub-modules according to the division of responsibilities, and then the modules can be subdivided and peeled off layer by layer.

2) Core entity extraction

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

  • Object analysis method

Entity:Objects 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.

Understanding from this concept is basically consistent with our understanding of object-oriented everything and objects. Therefore, the extraction of entities can also refer to the method of object analysis:independence, abstraction, hierarchy, and atomicity at a single level. The following figure is the analysis method of objects in "Thinking in UML".


  • Method of use case analysis
    By extracting keywords from business use cases, different keywords may express entities, relationships, attributes, etc., thus completing model analysis and establishment. Here I quote the content of Six Baht teacher in "Basic Abstract Method 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; second, find adjectives, which exist in "attribute" and "adverbial", find the basic adjectives The value of the corresponding attribute can be determined; then by supplementing the use case, refining, and defining the noun, slowly, we will get our domain model and the corresponding attribute. Finally, through the verbs and adjectives(existing in [predicate], [adverbial], [attribute]) to determine the relationship between them.

  • Method of problem analysis

This is the way mentioned in the "chat chat architecture", specifically by finding the subject of the problem, and then analyzing the life cycle of the subject, and then focusing on the key attributes and key relationships of the subject by distinguishing the key activities in the life cycle. It is recommended that you read the content of the first 9 chapters, which only totals 40 pages, and you may experience it. Here is an example from a book:

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

The author points out that there is no clear distinction between the main body here, this body is not just potatoes, but the implied people want to eat potatoes, including the two entities of people and potatoes, the relationship between these two entities is to solve the business Scene:How to eat? How to eat? Why eat? Therefore, the subject recognition is not clear, which may lead to deviations in the overall realization. Of course, such a stupid mistake will not be made in the actual process, but it also shows that the extraction of core entities is very critical.

3) The ultimate weapon:tell yourself

In actual business development, a business design implementation often satisfies the upper N business scenarios. Among them, there are commonality and personalized demands. In this process, we are easily confused by the similarities and differences between multiple scenarios, or the logic is not clear. Either overdesign or poorly thought out. I have observed that many classmates, including myself, tend to lose the focus of design at a certain business complexity. My approach is similar to business modeling, and it must be logically contrasted:at all points of design/logic ambiguity, all known scenes are set separately, and I will tell myself. Please note that this is "separately nested". At the current design level, the next scene is verified and then the next scene is verified. Find out the blocked and ambiguous points, reorganize and optimize the design. The results of system modeling guide our software design and implementation, so we must repeatedly sort out and get through. This iterative process is actually a process to improve the ability of the architecture. It will naturally be transparent when accumulated to a certain extent.

Back to the question at the beginning:

What is the mode? Through the above description of business modeling and system modeling, the model is simply a business mapping. 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 appeal?

How to build? Above, through the two dimensions of business modeling and system modeling, from the perspective of personal practice, the general routine is roughly described. The essence of modeling is actually an abstract process, but the above process of business and system modeling abstraction actually has two problems. It is not completely clear:

  • In business modeling, "collect books" into categories, establish a "big picture", and form a big picture. What dimensions are used to classify here? How to judge whether the classification is correct?
  • How to remove "peeling onion" in system modeling? According to what? How to divide the levels and areas in the above architecture diagram? Where is the border?

Speak back to abstract

Paul Hudak, one of the designers of the Haskell language, once said a slightly exaggerated statement:The three most important things in programming are:abstraction, abstraction, and abstraction.

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

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

Baidu Encyclopedia definition:

To extract and summarize their common aspects, essential attributes and relationships from specific things, and discard individual, non-essential aspects, attributes and relationships. This kind of thinking process is called abstraction.

If a more refined summary:abstraction is to do subtraction and division. By discarding the non-essential and insignificant parts, focusing on the essence of the problem, and taking the rough and fine; by looking at the essence through the phenomenon, we discover the commonalities between different things, seek common ground in differences, merge in the same kind, that is, divide. The modeling process 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. The core is to meet the needs of business scenarios. In fact, there is also a boundary problem behind this.

Abstract perspective

There are abstractions everywhere in life, but we seem to have less thinking about why it is one way or another. Abstraction is angular.

In life, we often say "my point of view is...", in fact, "point of view" here is a perspective issue, from a certain standpoint or perspective, the view of things or problems. In terms of common objects in life(as shown below), can we quickly tell the similarities and differences.


As already marked in the figure, we define the distinction between chairs, tables, stools and cabinets from the perspective of function, but there are obviously many, many angles, such as:materials, text, height and so on, from different dimensions In the past, there would be completely different expressions of similarities and differences, so what is the essence? The essence is:

  • The abstract angle is actually a classification angle. Different angles will lead to completely different modeling directions and results.
  • The abstract angle is the direction and purpose of modeling("Ass determines the head").

Back to the two questions before us, in business modeling we talked about categorization, according to what to categorize, the answer is coming out, according to our business process to categorize according to the role of the customer, and back to that The initial question:Who is the customer? What is the core appeal?

At the same time, as we mentioned above, modulo is the mapping of business. Based on the understanding of abstraction, we can further expand:modulo is the business mapping under the determination of abstraction.


Abstract levels

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

  1. My May 18th San Francisco Chronicle
  1. The San Francisco Chronicle on May 18
  2. The San Francisco Chronicle
  3. A newspaper
  4. A publication

In these five sentences, we can feel the level of abstraction. The higher the level of abstraction, the less detail, and the stronger the universality. Another example is the abstraction of the network model and the abstraction of the operating system kernel in the following figure. We can clearly see the different levels of abstraction, which is to filter different information, and the information left behind is the information required by the current abstraction level. In terms of system design and implementation, the higher the level of abstraction, the closer to the design and the farther away from the implementation. At the same time, the abstract model is not constrained by details, the higher the stability, the greater the universality, and the higher the reusability.


So what is the basis for the abstract division of levels here? What are the principles? My experience is that the basis for dividing the level of abstraction mainly includes two:

  • Layered in an abstract angle(may be a layer is an aggregation of multiple angles)
  • Face change layering(use layers to isolate changes)

In fact, this can not fully explain how to layer, what is the principle? I think these are the most common principles:

  • Go down publicly
  • Personalized going up
  • The lower layer can exist independently of the upper layer
  • Control changes in the lower layers

The benefit of considering the level of abstraction is that no matter at which level, we only need to face limited complexity, so we can concentrate on what the abstraction at this level is and what information we want to express.

Abstract border

In addition to angles and levels, we also need to consider the abstract boundaries. If the layer considers the expression in the vertical dimension, then the boundary considers the expression in the horizontal dimension. How to determine the boundary, a general principle is to divide according to responsibilities, the responsibilities here is actually the division of labor. Once the responsibilities are determined, we do not need to put the entire business situation into analysis when we do the modeling analysis. We only need to consider the upstream and downstream under the current division of labor. This greatly reduces the amount of information and naturally The complexity of the fields we face will also be reduced to a certain extent.

If you must give a definition of the boundary, my understanding is:boundary is to determine the core business activities, extract core entities, and further determine the results of the core life cycle of the entity under the abstract angle of determination. There may be a little bit around, the keywords are:core business activities, core entities, core entity life cycle.

Taking the live entertainment industry as an example, the following picture contains the full life cycle of the business at the highest level of abstraction, what is the main body at this level of abstraction, my understanding is the ticket, the result of the project production is the ticket, distribution or e-commerce service It is the sale of tickets, and the on-site verification of tickets, and the life cycle of tickets as the core entity has ended.


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

Project Management -> Venue Seat Distribution -> Box Office Forecast -> Event Management -> Quota Management -> Paint Block -> Box Office Planning

From the perspective of production, the core entity is not a ticket, but a show(a show or an event that determines the time, location, and content). All key business activities are based on the event. The production field needs to be considered The main is the core life cycle of the event.

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

Abstract evaluation

In front of us, we basically made clear the angle, level and boundary of abstraction, and determined the abstract result 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 interconnection between modules in the software structure

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

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

  • Divide from one angle at a time, and then examine from multiple angles
  • Refine and optimize models and designs by combining and splitting(abstract results)
  • Key review points:
    1. Coupling:reduce communication between modules
  1. Cohesion:single function
  2. Changed isolation:reduce information dependence, build isolation layer, virtual layer

Abstract Methodology(Routine)

I think, at this point, we have clarified the previous two issues:

  • In business modeling, "collect books" into categories, establish a "big picture", and form a big picture. What dimensions are used to classify here? How to judge whether the classification is correct?
  • How to remove "peeling onion" in system modeling? According to what? How to divide the levels and areas in the above architecture diagram? Where is the border?

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

  • There are two ways to abstract, one is from top to bottom, the other is from bottom to top
  • Business modeling is an abstract process of induction and deduction from small to large, from partial to overall, bottom-up
  • System modeling is an abstract process of disassembly and segmentation from top to bottom, from whole to part, top to bottom
  • But not absolutely, top-down and bottom-up, often switching randomly in the process

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


How to draw an architecture diagram?

Back to the topic, if the above question is clear, the next thing is relatively simple. For the question of what the architecture diagram is, we can extend the previous equation:architecture diagram = expression of the architecture = expression of the architecture at different abstraction angles and different levels of abstraction, which is a natural process. Instead of having a graph before business processes, system design, and domain models, but instead, use graphs to express abstract thinking and content.

So what's the use of architecture diagram? To whom? To answer this question, you need to make it clear why you need to draw the architecture diagram. At the same time, you also need to consider the question:is the more architecture diagram the better, the more detailed the better?

What is the purpose of drawing the architecture diagram?

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 placed on the What level, we must consider the "customers" faced by the architecture diagram. Different customers have different demands(in fact, angles and levels), in different abstractions. The information content expressed by the hierarchical architecture diagram can be completely different. Taking what the current team is doing as an example, there are at least several types of target customers for the architecture diagram:

  • The roles of various teams participating in the project(business, product, development, testing, security, GOC)
  • Customers outside the project(external customers, external review experts)
  • TL at all levels(reporting, cross-BU, cross-team collaboration communication)

Therefore, to draw the architecture diagram, we must first clarify the purpose of communication and the customers we face. Only by clarifying these two points can we achieve the two goals mentioned above more specifically:solve communication barriers and improve collaboration efficiency.

How to draw?

Let's talk about classification

Architecture diagram classification is essentially from different perspectives and different abstract angles, and makes clear and simplified descriptions, covering features and ignoring irrelevant aspects.

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

Business domain >Subdomain >Module >Submodule >Package >Class >Method

some of:

  • Lower level of abstraction:application internal package diagram, class diagram; a field:entity diagram, sequence diagram, state diagram, use case diagram, etc.
  • Higher level of abstraction:with certain complexity, such as microservice architecture, interaction diagram between systems, domain/subdomain architecture diagram, entire system architecture diagram, etc.

Of course, there are many other classification methods, 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 think clearly about who to face and what to solve, and then think about which perspective and which level of the architectural diagram is abstracted. In the projects we are currently working on, there are times when we need to communicate with foreign business experts and technical experts. Everyone does not have a clear standard definition, express the problem clearly, and reach consensus. This is the most critical. The granularity, category, and content can be gradually improved, coarse and refined, and iterative optimization.

Let's talk about composition

In the composition part, all of us have drawn class diagrams using UML, involving generalization, aggregation, composition, dependency, etc., and expressed them with different dashed solid lines and arrow styles. Therefore, drawing the architectural diagram needs to consider the constituent elements of the architectural diagram. To ensure consistent understanding, the constituent elements of the architectural diagram may involve:

  • Boxes, various shapes, dashed solid lines, arrows, colors(what do different colors mean) and text content
  • What does the dashed solid line mean? 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 association?
  • The interaction type can be synchronous or asynchronous; the associated type can refer to dependency, inheritance, and implementation

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

How to judge the quality of the architecture diagram

The quality of the architecture diagram, I understand that there are mainly two directions. One is to jump out of the diagram itself to see whether the abstract design rationality of the business domain meets the requirements of "high cohesion and low coupling". This needs to go back to the previous one. Business modeling, system modeling, and abstract processes to find answers. The other direction is the diagram itself, the following points are for reference:

  • Consistent content terminology, consistent information granularity, clear legend, uniform color type, beautiful
  • The information in the picture is related to the corresponding level of abstraction and meets the needs of stakeholders(partners)
  • A good architecture diagram does not require extra text explanation! Has the audience received exactly the information that it wants to convey; if it caused more questions than it can explain, then it is not a good architecture diagram



                                                              Have-do-be    be-do-Have                          



( )
( )
Thinking in UML