The login
registered
Write an article
Home page
Download the APP

Visual Architecture Design — Introduction to C4

Both keys

Visual Architecture Design — Introduction to C4

2018.06.25 00:33:26

Many years ago, XU Hao said something that inspired me a lot. He said, “The architecture is not on paper, but in everyone’s mind.” This tells us that even people who work in a team day in and day out may perceive architecture differently. Everyone says the same thing, but the picture in their mind is still different. Over the years of my work, I have come to recognize the truth of this statement. Software development is a team effort, and a confused understanding can lead to meaningless corruption of architecture, an unconscious accumulation of technical debt, and a worthless increase in maintenance costs.

Recently I heard a saying, “The reason why those wonderful schemes fail is because they are not designed to accommodate human stupidity”. It’s true that the ideas that people end up choosing are ideas that are a decade or even decades old, but they will sleep in academic dust until the technology is advanced enough to be “compatible” with human stupidity. Coarse language does have a problem, however, turning a thoughtful question into an emotional one. It’s easy to blame some bad things on human stupidity, vent your dissatisfaction and then stop thinking. As knowledge workers, we can’t stop thinking, we need to think about what kind of human stupidity, and how to avoid or “compatible”.

To be sure, it’s silly to get together every day and try to get the software right when you have different ideas about the software you’re developing. In order to be compatible with this kind of stupidity, we need to adopt a visual approach.

The main reason for visualization is that the language is unreliable. Human language is so arbitrary, if you want, you can say you’ve seen a square circle and argue with someone about it. But you can’t draw a square circle anyway, and that’s why we need visualization.

Today we introduce a tool called C4 Model, which is one of the rare tools I have seen in recent years that has a lot of resonance with my cognition.

Over the years of consulting, the tool’s authors have often found that many individuals draw different architectural diagrams, not that any of them are wrong, but that each person has a different level of abstraction. It seems that there is such a thing as levels of abstraction, but it is difficult to explain them clearly. Therefore, the author puts forward the concept of scaling by analogy with maps. (I taught the same concept to my students two years ago.)

At the national level

At the provincial level

The municipal

The road level

The above four maps illustrate that when we look at an “architectural map” of the real world, we have to zoom in and out, deliberately ignoring details at each level to convey the information at the current level of abstraction. So he puts architecture into four levels of abstraction by analogy:

image.png

From top to bottom are the System, Container, Component, and Code. Well, why is it called C4, because the diagram of the System is called the System Context diagram. It’s a lot to get four Cs.)

Based on these four levels of abstraction, the C4 model consists of four core diagrams and three subsidiary diagrams that describe different scenarios, as described below.

Four core maps

System context diagram

image.png

As shown above, this diagram represents the relationship between the system you are developing and its users and the systems it depends on. From this figure we can already see several key figures of the C4 figure:

image.png

C4, after just a few elements: relationships – arrowed line, described elements – square and roles, and relationships – online text, the description of the elements – square and characters in the text, the element tag – square and the character of color, dotted box (dotted box in the inside of the C4 expressiveness are limited, I think I can give the dotted box more extended space)

By redefining the meaning of square and dotted box in different levels of abstraction, we can only express in one level of abstraction, so as to avoid the problem of confusion in levels of abstraction when expressing.

So in the system context diagram, the squares are the software systems, the blue ones are the systems we focus on, the systems I develop (or analyze, depending on who I am), the gray ones are the systems we rely on directly, and the dotted boxes are the boundaries of the enterprise. Through these graphical representations we can see how the systems relate to each other.

Container figure

image.png

When we zoom in on a system, we see containers, as shown above. The C4 model says the system is made of containers. The container is, in my opinion, the biggest innovation of the C4 model, especially in this era of rapid collapse of monomers. The so-called container, neither Docker container, nor JavaEE container, is borrowed from the process model, each container is a kind of existence with its own independent process space. A separate process space can be considered a container, whether it is a separate process space on the server or in the browser. Of course, if you do a good Container, Docker Container and this Container can be matched one by one. With this concept in place, we can express our architecture more clearly, rather than using vague things all the time.

Component diagram

image.png

When we zoom in on a container, we see the components, as shown in the figure above. The component does a good job of packaging the interface and its implementation classes into a concept to express the relationship. I personally feel that sometimes things that exist in code but are not interfaces, such as services, controllers, and repositories, can also be represented in component diagrams. If you have learned something about architecture without a clear level of abstraction or a legacy of the monomer era, You can draw some component diagrams to illustrate your understanding. Here I draw my understanding of some concepts in DDD tactical design:

image.png

This expression is much clearer than vague, stacked text, and even if MY understanding is wrong, it is easy to point out and discuss.

The code in figure

Code diagrams are nothing to talk about; they are very detailed diagrams like class diagrams in UML. They’re not drawn, they’re generated in code. Draw code diagrams only for very important components that have not yet been coded.

So that’s the core diagram of C4, and we can see that the definition of four different levels of abstraction makes it easier to fix the level we’re talking about, which IS where I think C4 is very valuable.

Three extension diagrams

There are many dimensions to consider in architectural design, and only four core diagrams are not enough. Therefore, the author provides three extended diagrams to allow us to focus on more dimensions.

System Landscape map

image.png

It can be seen that a system landscape diagram is a richer system-level representation than a context diagram. Unlike context diagrams that focus only on systems and their direct relationships, even indirectly related systems are identified, as are the users of those systems and their relationships with each other, but the internal users are marked in gray.

What’s the use of this graph? When we analyze an enterprise, we need a tool to help us dig down to the bottom of a company, so that we can see the whole picture of the enterprise so as to understand the correct positioning of the local and do a good job of local design for global optimization. Before, I tried to teach people to master this ability by using two tools, red card and event storm, which are modeled with four colors. When students are programmers, they cannot quickly master this kind of analysis skills by following the lead. After all, the thinking of programmers is somewhat different. But after I used the systematic landscape map, the students mastered this analytical ability with no difficulty. Therefore, I later used this diagram to teach programmers to explore the digital panorama of the enterprise. The effect is excellent and I recommend it to everyone.

Dynamic figure

image.png

Dynamic diagrams are different from other diagrams that express static relationships. They are used to express dynamic relationships, that is, how different elements are called to complete a business. So dynamic diagrams work not just at one level, but at the system level, container level, and component level, expressing different goals.

I have previously written a series of articles called “Think like a Machine”, in which I also invented a similar graph. Different from his relationship line, I pay more attention to the data, and the effect is also very good.

When do you use dynamic diagrams? A small example, before I do a small internal system, only an experienced engineer with more than 10 graduates, I asked them before starting work all draw a picture dynamic, by experienced engineers to evaluate their way of thinking is correct, if there is a problem, just before you start to kill bad design. Graduates and junior engineers alike are much less able to change code than they are to write it, so it helps to kill a bad design before it is implemented.

Deployment diagram

image.png

The previous diagrams are all from a development perspective, but an architecture that hasn’t given enough thought to deployment can easily become an operational disaster. So the authors provide a deployment diagram. Given that the DevOps movement is in full swing, this chart can be a great bridge between Dev and Ops. In practice, we find that the differences in Dev and Ops concerns and language differences are very clear in this diagram.

The largest solid box on the diagram is different from the dashed box in that it represents a data center, which makes sense when you start thinking about remote provisioning. Data synchronization and the number of instances will affect the content of your deployment diagram. The deployment diagram is basically container-level, which can well express how many instances of a container are deployed, what kind of operating system is deployed, and how many containers are deployed on a node. In actual use, we found that there is too much information to consider. It abstracts terms like Small and Large from amazon instance specifications to express machine configurations, improving the accuracy of communication between development and operations.

Why is C4 recommended

Intuitive enough, easy for programmers to understand, easy to use. As we said at the beginning, only the architecture diagram is in everyone’s head, so if we use a tool, the understanding of the tool itself is prone to error, and we are trapped in an endless loop of understanding. After teaching many different tools, the C4 model is the easiest to understand and use. Perhaps the concept is to reuse some of the cognitive models that the programmer already has, teach the programmer, can be used quickly, and ask some high-quality questions.

conclusion

In the world of thinking, we are all blind. We think we know a lot of things, but when we draw them out, we find that many things we have not thought of and many of our thoughts are confused. At the same time, others can give us feedback.

With the tools above, we can start on the road to visual architectural design, but there is still one inner demon to overcome. In our culture, it’s humiliating to be wrong, so we like to avoid being challenged by others with vague descriptions, while visualization allows us to accurately describe our understanding and welcome challenges from others. It’s not easy to get over this hurdle, but once we get over it and we form a positive interaction, we will make rapid progress, thus leaving the closed people far behind and gaining the impetus of growth at the organizational level. I’ve personally gained deeper insights from conversations with others, some of which I’ve shared in this post, and others I’ll share in the next post.

Image credit: c4Model.com/

Software development thought set

Both keys
advertising

mo4tech.com (Moment For Technology) is a global community with thousands techies from across the global hang out!Passionate technologists, be it gadget freaks, tech enthusiasts, coders, technopreneurs, or CIOs, you would find them all here.

Visual Architecture Design — Introduction to C4

Visual Architecture Design — Introduction to C4

Visual Architecture Design — Introduction to C4