How To Draw Clean Architecture Diagrams

Architecture Drawing: Tools and Methodology

This article describes how to use graphs to draw and communicate your architectural design, focusing on the general methodology of architecture drawing.

By Chuheng

Preface

At first glance, the term "architecture drawing" seems somewhat obscure. Even so, when it comes to "engineering drawing", near programmers with an engineering science background should already exist familiar with it. I tin even feel the ups and downs of those years in the dormitory with a compass on the left hand and a ruler on the right hand.

Software engineering is likewise engineering. Therefore, some basic theories of conventional engineering cartoon are likewise applicable in the software industry. However, the differences between the software and traditional manufacturing industries are so essential that their demands and methods in cartography are quite different as well, which cannot be straight applied. As a practitioner in the software industry, you may not understand applied science drawing at all, only you must sympathize architecture drawing. This is a compulsory course for every developer in their careers.

The 2nd half of this commodity describes how to use graphs to describe and communicate your architectural design. It is worth emphasizing that this article volition focus on the general methodology backside those fantabulous methods rather than on a single method or tool. It ways that this article will focus on the essence, commonality and best practices of compages cartoon. I hope this commodity can serve as an introduction to stimulate everyone to follow, examine and think about the architecture and drawing function of your daily work. If this article can really help you ameliorate the drawing efficiency and issue even just a lilliputian bit, that would be great.

What Is Software Architecture

Definition of Software Architecture

The definition shown past IEEE is that architecture is the set of key concepts or backdrop of the organisation in its environment, embodied in its elements, relationships, and the principles of its pattern and evolution.

Software Engineering Institute of Carnegie Mellon University (CMU) defined the software architecture of a calculating organization is the set of structures needed to reason about the system, which incorporate software elements, relations amidst them, and backdrop of both.

Uncle Bob defined compages of software arrangement in Make clean Architecture is the shape given to that system by those who build it. The grade of that shape is in the segmentation of that system into components, the organization of those components, and the ways in which those components communicate with each other.

Core Elements of Architecture

Based on authoritative definitions above, software system architecture usually contains following four types of core elements.

Elements: A system tin be split into a grouping of elements of modules, components, structures, and subsystems.
Relationships: Relationships between different elements are interaction, dependency, inheritance, composition, and assemblage.
Properties: Properties that each element has are names, responsibilities, interfaces, implementation restrictions, etc.
Principles: Reasons for the design include the basis for splitting, design principles, determination-making reasons, etc.

Why Architecture Is Important

Architecture - Blueprint for Arrangement Implementation

Recently, in that location is a very popular web series about a strange suspense story in a skyscraper called "A Murderous Thing in Horizon Belfry". I want to ask a question here. Who built the skyscraper? Maybe you will recollect the question as meaningless that the skyscraper is only built by construction workers brick by brick. However, if you recollect about it again, y'all will find that at that place are a agglomeration of architects and civil engineers who are most concerned about the skyscraper. They don't work like construction workers, simply without their hard piece of work of those tedious and rigorous design drawings, skyscrapers cannot exist erected as rapidly and stably every bit self-built houses. In rural areas, self-built houses tin be synthetic but with workers' experience and imagination.

Information technology is these blueprints that laid the basis for worker's division and cooperation of labor besides every bit acceptance criteria. Workers just need to follow blueprints and practice their jobs. Every bit long as blueprints are correct and at that place is no deviation in the construction process, the skyscraper will eventually be completed successfully.

Like the construction, automotive, or whatsoever other engineering industries, software likewise requires blueprints earlier it is coded. One of the most important blueprints is architecture design. With no architecture but only vague ideas, you might be able to create some squeamish and useful things such equally Linux 0.01 like traditional craftsmen. However, it is unlikely that a complex software organization on the scale of a skyscraper, for example, the modern Linux system, could be built in an engineering mode with a team. For i thing, the thinking ability of homo is limited. And then, we must rely on highly abstruse and simplified blueprints of architecture to brand the cosmos, understanding, analysis and management of complex systems viable. For another, big systems that reach a certain level can only be completed through multiple sectionalization of labor. The architecture is just the important foundation for communication and collaboration among people.

Architecture is the Foundation of Advice and Collaboration

The concluding value output of a software project is the software arrangement. As the soul and framework of the software organization, the architecture can play post-obit roles.

Understanding alignment: All software systems are designed to encounter user needs. Whereas, compared with traditional technology industries, software is more than flexible and noesis iterates faster, then there are infinite possibilities for implementation. Architecture design is to cull the near suitable implementation method. Therefore, lots of fundamental routing decisions are involved including reasons for splitting and for choosing applied science A rather than technology B. These important technical decisions need to be recorded and synchronized by architecture clarification. By doing then, all project team members tin can reach a consensus on the understanding of the whole system.
Piece of work quantification: I of the near important steps in project management is working hours assessment, which is the direct basis for determining project schedules. Apparently, workloads of a project cannot exist scientifically quantified only by product requirement document (PRD) or interaction graphs. This is because it is difficult to intuitively decide how much code needs to be written and how hard it is to achieve behind a brief requirement or a simple folio. With a clear and explicit architecture, most evolution piece of work tin can exist visible, anticipated and detachable theoretically, and exist quantified more accurately. Of course, accurate workload cess has always been an unsolved difficulty in the Information technology industry. The actual schedule will be affected by too many unknown factors, including skill proficiency, mood, and nutrition of programmers.
Standard terminology: Programming, as a creative task, is similar to writing science fiction novels from a certain perspective. All writers of good science fiction novels like to create concepts, such equally Sophon in The Three-Trunk Problem. If you lot oasis't read the novel, you certainly have no idea of what information technology is. Compared with science fiction, software arrangement is going further in creating concepts. Afterwards all, the earth in novels is usually based on our existent earth, while the world in software depends on modeling of programmers. Slightly more than complex software systems will introduce some domain-specific or even make-new concepts. In order to avoid the communication barriers and ambiguity in understanding during the projection, terms describing these concepts must exist unified. One important purpose of the architecture is to define and explicate all fundamental concepts of a system clearly, and apply standard and consistent terms in the entire architecture design and description process. In this fashion, the communication for everyone will be smoother.
Specific content: Compages description is a specific grade of materialization. Interaction designers need to collate prototype diagram when discussing product interactions and programmers demand to await directly at the code when discussing code details. Simply like them, when we discuss some college-dimensional technical issues, the essential entity in the architecture must be considered. Or otherwise, it will be either a bunch of people talking meaninglessly without any footing, or finding a whiteboard to draw every fourth dimension we communicate. Information technology is obviously not a long-term solution due to time-consuming and information loss.

Noesis accumulation and newcomer training: Compages should exist continually accumulated and maintained every bit document assets like important code. Moreover, architecture is an of import basis for newcomers to understand and operate system apace. Don't leave your system only with legacy code and without architecture documentation. Otherwise, you will be in struggling to maintain the project alive simply with some leftover design memories from mouth to mouth.

Architecture Determines Product Quality

How to measure the quality of a software production? The preceding figure shows the software production quality model defined by ISO/IEC 25010, which covers following viii aspects.

Functional Suitability: Functional integrity, functional definiteness, and functional appropriateness.
Operation Efficiency: Fourth dimension beliefs like response time, resource utilization, and chapters.
Compatibility: Interoperability and coexistence capability like coexistence of multi-version components.
Usability: Learnability, operability, user error protection like automated error correction, user interface aesthetics, and accessibility.
Reliability: Maturity, availability, fault tolerance, and recoverability.
Security: Confidentiality, integrity, non-repudiation, authenticity, and accountability.
Maintainability: Modularity, reusability, analyzability, modifiability, and testability.
Portability: Adaptability, installability, and replaceability.

All points listed in the quality model to a higher place demand to be considered in architecture design. Except function suitability, all other points vest to non-functional requirement, which is the standard for distinguishing expert architectures from bad ones. In other words, good architecture design volition not only satisfy the most bones functional requirement for the worst compages design tin do the aforementioned. More importantly, skilful compages pattern also meets many other not-functional requirements.

You lot of course cannot take them all. Compages is a game of tradeoff just like our life. The worst result is nada volition be done in the end. Proficient architects should seem like "know nil", but actually "know everything". They should know all stakeholders in the system, try to mine all parties' concerns, residual their own decisions, and finally achieve the ultimate goal for all-win situation.

Additional Reasons

At that place are really more than reasons than those listed in this page.

Architecture contains all the about important early on decisions. These decisions will in turn affect all subsequent technical decisions. Therefore, although it is difficult, the early compages design needs to be as rigorous and cautious as possible to brand it right at one time. Otherwise, the cost of error correction will be high in latter stages;
Architecture has a very high reuse value within the organization because there are many commonalities of products in the same organization, such equally requirements, restrictions, and environment. This means it is suitable for maximizing reuse at the architecture level and avoiding repeated resolution of similar problems.
Conway'due south Law points out that the software architecture reflects the organizational structure. So, adept compages can brand the organizational construction more efficient.
The larger and more complex the arrangement is, the more than important the architecture is. Only a skillful architecture can effectively control, manage and reduce system complication.
Maybe you will become confused as if there are infinite kinds of explanations of architecture. Simply don't worry about information technology. Gang of Four (GoF) has described in their pattern model: "compages is near the of import stuff. Whatsoever that is." So just call back that architecture is very important.

How to Design a Expert Architecture

Subsequently understanding concepts and the importance of compages, yous have just begun to become a real builder. The question of how to design a practiced compages is obviously a wide and profound topic, but it is not the focus of this article. Therefore, only some basic principles and classic modes are presented in this commodity. Architecture blueprint is closer to an empirical subject field. It is not plenty to blurt out some mysterious and lofty theoretical concepts. You lot also need to put yourself into practice and endeavour to deliberate architecture design through the combination with actual piece of work and business scenarios. Or otherwise, you will always just discuss about theories.

Principles

SOLID principles are a set of classic and popular architecture principles.

Single responsibility principle: It is similar to "Do 1 affair and do it well" advocated past Unix philosophy.
Open / closed principle: It uses extension instead of modification (destroying existing encapsulation), which is similar to the idea of immutable in functional expression.
Liskov Substitution principle: The "Is-A" human relationship of inheritance can be proofed simply when parent classes announced, the bracket must appear.
Interface segregation principle: Exercise not permit ane class to depend on an interface that is not used in some other form. In short, information technology ways to minimize the interface dependency and coupling between components.
Dependency Inversion principle: Abstruse classes and interfaces, rather than concrete implementations are relied on. Let low-level modules depend on the stable abstraction of high-level modules to achieve decoupling.

In addition, following principles volition be obeyed as much as possible when designing the architecture. These principles are similar to the above SOLID principles in essence.

Orthogonality principle: The orthogonality of components separated from the aforementioned level of compages should be ensured, that is, these components should be mutually contained and accept clear boundaries without overlap.
High cohesion principle: The within of the aforementioned component should exist highly cohesive, like an indivisible whole, or otherwise information technology should exist separated.
Low coupling principle: Coupling between different components should be reduced as much as possible to reduce the mutual bear on of changes and enhance component reusability.
Change isolation principle: The essence of many architecture principles and patterns is the isolation of changes. When changes occurred, other stable parts may need modification on code and re-testing, or may cause subconscious problems. Past isolating parts that are expected to undergo changes, these bad impacts can be reduced.

Patterns

Architectural patterns are not same as design patterns we often discuss. However, if we translate them only from the perspective of "patterns", the idea of both is the aforementioned, that is, a general and reusable solution to a commonly occurring problem within a given context. The master difference is that architecture patterns used at the architecture design level are more loftier-dimensionally abstract and more than comprehensive.

Common architecture patterns include some traditional patterns such every bit layering, C/S, MVC and event driving, and too some new patterns such equally cloud native, microservices, and Serverless. Different patterns have different applicable scenarios. A mature architect should be similar a feelingless killer that always objectively evaluate and choose the most suitable solution for the moment, even if it will seem unproblematic and slow. On the reverse, an immature architect always wants to practice something, such as forced applying microservices architecture, rather than solving issues.

How to Describe Your Architecture Design

With a adept architecture design, the road to the successful architecture has already reached more than half. Information technology is just like a delighted immature director who meets a good script for the first time. He seems to foresee the bright box role later on the movie is on. Of class, the rest of the road is not equally flat as imagined. The aforementioned pattern volition take different qualities past different architects. A good builder should accept the power to describe a good architecture design. Even if he cannot add more than points to the wonderful part, he should non lose points due to improper description of its grade. Otherwise, he will experience so wronged and sorry like losing points in writing in an exam.

Significance of Compages Description

Why should I draw the architecture rather than just keeping information technology deeply in my mind? There is a proverb in the west that the faintest ink is better than the best retentiveness.

Anything without persistence is volatile, just like memory. In improver, as mentioned before, architecture is the basis for communication and collaboration. Without architecture description for relative person in the object, the only carrier of communication and broadcasting volition exist lost.

According to my personal observations, there is no objection to the "architecture demand description". So most projects produce some sample compages description documents more than or less. Still, at that place is a huge difference between architecture description and practiced architecture clarification, which is even huger than the difference betwixt "having compages description" and "having no compages description". If y'all have read countless architectural documents similar me, you may feel the same.

Ways of Architecture Description

For a same thing, a writer uses words to draw it, while a painter uses paintbrushes to draw it. Both of them want to present the aforementioned information, just different ways of description will atomic number 82 to huge divergence in upshot. Architecture clarification is also divided into text and diagram, each of which has its ain advantages.

Text depends on a rigorous and complete prepare of language. Then its description can be very precise and exhaustive, and information technology is also very convenient to be written on whatever notepad software. In add-on, but like writing code, version command can be hands completed for text with the help of simple text tools such as diff. Past doing then, you can easily compare detail differences betwixt different versions.
By contrast, diagram does non have unique characteristics of text, but it also has its own unique advantages. Diagram is intuitive and visual. It conforms to the inherent visual recognition instinct of human beings. Moreover, diagram is stronger in expression. Virtually of the time, a small diagram can present information such as spatial location human relationship, color classification, and icon shape, which may be unable to be comprehensively described with text.

You may recall that tin can't nosotros have both text and diagram? Of course we tin can. The ideal architecture description must be illustrated with both text and diagram, only the real world is plainly crueler than an ideal one. In actual software programs, it is unlikely to give you enough fourth dimension to produce a perfect architecture document starting time. Considering the render on investment (ROI), y'all will definitely give priority to diagram.

Reasons of Giving Priority to Diagram

The Manifesto for Agile Software Development mentioned that working software is more of import than comprehensive documentation. This, of course, does not mean that there is no demand to write documents. Information technology just advocates in that location is no need to write too comprehensive documents. The reason is that comprehensive documents expend a lot of writing and maintenance costs, which does not arrange to active development principles of small-step iteration and rapid response to changes.

So, in today's era of comprehensive agile evolution, how tin nosotros also follow the trend for more quickly writing architecture documentation? ROI is your friend, meaning that you should try to express the core content with simplest expressions. From content, the high ROI part is usually the top-level overall architecture or the core process. This is as well reflected in the C4 model concept that will exist introduced later. From form, diagram has an unparalleled expressive advantage compared with text, which is obviously a selection with higher ROI.

Reason of Learning to Draw

Is it necessary for u.s.a. to learn how to draw? Architecture diagram is non art painting or only a bunch of stripes, and anyone with a little technology knowledge can depict information technology. The painting is a bit ugly? It doesn't matter. Yous merely need to align lines and frames and add colorful background gradient or something. So it will await very professional.

Perhaps you volition pour scorn on that again and recall that it is plainly not so simple. Indeed, everyone knows the truth. Architecture drawing, like engineering drawing, is a matter that needs to be taken seriously and rigorously. Yet, in reality, about people really don't have the time to practice that. For example, the two common architecture diagrams posted to a higher place. Needless to say that the starting time diagram is good to satisfy yourself rather than prove to others. The second diagram looks fine, but actually, when you measure it more carefully, you will find a lot of ambiguity and dubiety in this diagram. For more than information, please refer to the source commodity of this picture: The Art of Crafting Architectural Diagrams.

And so, being able to describe diagrams doesn't hateful beingness able to draw diagrams well. Information technology is difficult to seize key points for drawing a nice and readable diagram only by intuition and comprehension. You lot notwithstanding need to learn continuously and practice deliberately. In improver, wrong diagrams are often worse than no diagrams. Even if simply thought that "It's OK to be but about right", you should at least sympathise some key elements of scientific drawing. These key elements volition avoid blurring an already complicated project, or even confusing or misconducting users.

Objectives of Architecture Cartoon

Before discussing specific cartoon methods and tools, nosotros need to erect clear cartoon objectives. Tools are the ladder of human evolution. However, if tools are understood and used improperly, homo volition hands exist restricted or even enslaved by tools in return, forgetting original objectives of inventing and using tools. There are already so many methods and tools for compages cartoon. The original objective I think is to plow drawing into a scientific technology from a gratuitous arts and crafts, achieving its systemization, strictness, integrity and standardization. At the same fourth dimension, the process of drawing can be repeatable, sustainable and efficient.

P.Southward: Please forgive me. I was likewise busy at that time, so pictures in PPT accept to be very simple.

Architecture Cartoon Methods and Tools

After cursory introductions in previous chapters, I believe that everyone has enough understandings of background noesis for architecture cartoon. In this chapter, I volition specifically listing and describe some typical architecture drawing methods and tools. Some of which are common and some of which are rare. The focus is to hope that through the horizontal comparing of various methods, everyone tin can understand well on the nature of drawing methods.

Unified Modeling Linguistic communication

Unified modeling linguistic communication (UML) is probably the most familiar drawing method for most people. The latest version of UML two.ten consists of following 2 types of diagrams.

Structural diagrams: Through object, belongings, operation, and human relationship, structural diagrams emphasize static structure. The most mutual types of structural diagrams include course diagram, component diagram, and deployment diagram.
Behavioral diagrams: By showing collaborative relationships among objects and state changes inside objects, behavioral diagrams emphasize dynamic behavior of the organization. The about common types of behavioral diagrams include use case diagram, activity diagram, sequence diagram, and state machine diagram.

The universal UML contains xiv different types of diagrams, which tin can comprehensively meet diverse drawing requirements in software design, including architecture drawing. At the same fourth dimension, equally UML regards itself every bit a language, it has rigorous definition on diverse notations and semantics without any dubiety or ambiguity. In addition, later on decades of evolution and promotion, UML has already become a standard norm widely used worldwide. The subconscious value of UML is the low toll for communication within the team past supposing that most technicians tin can cover the meaning and usage of UML.

However, although UML was once regarded as the silverish bullet in software blueprint, information technology is still non omnipotent. The most criticized shortcoming of UML is that it is as well complicated. Information technology is not UML itself to blame considering it is designed to be universal, rigorous and powerful enough afterwards all. These goals run counter to simplicity, and let it evolve stride by stride into today'southward complicated and rigid language. Although we confidently supposed that most technicians can comprehend UML, I think an average of xx% would be skillful if you ask me how many of UML can they cover. Nigh of technicians only know several common grade diagrams and sequence diagrams. It is estimated that information technology is even difficult for them to accurately limited meanings of various arrows in course diagrams.

Whatever, UML should all the same be one of the most unremarkably used and necessary tools for every developer. Of course, it should not exist the but ane, considering in that location are some other good tools and methods that cannot be missed below.

4 Plus 1 View Model

What is "4 plus ane"? Information technology doesn't matter if you lot haven't heard of it. Have yous ever heard of the famous TV show named "6 plus 1"? "6 plus one" has no relation with "4 plus 1" at all. They just sound similarly, similar Sherry, Shirley, and Shirly.

So, what exactly does "4 plus one" hateful? Wikipedia defines it every bit a kind of view model and architecture describing software-intensive systems through multiple coexisting views. These views are based on viewpoints of different project stakeholders, such as finish users, developers, organization engineers, and project managers. "4 plus one" consists of 4 basic views and some selected apply cases or scenarios, that is, boosted "plus 1" view. Following are specific meanings of each view.

Logical view describes functions provided by the arrangement for terminate users, which are usually represented by class diagrams and country car diagrams of UML.
Process view describes dynamic beliefs of the system, including execution process and interaction. It is usually represented by sequence diagrams, activity diagrams and communication diagrams of UML.
Development view explains the organisation from the perspective of programmers. It is also known as implementation view, which is ordinarily represented by component diagrams and bundle diagrams of UML.
Physical view describes the system from the perspective of organisation engineers, including the concrete topology of system components and physical connections between each component. It is likewise known as deployment view, which is commonly represented by deployment diagrams of UML.
Scenarios are used for describing an compages based on a small number of utilize cases or scenarios, including the interaction sequence among various objects and processes in the organisation. It is also known as utilize-case view. These scenarios can be used to identify architectural elements, illustrate and verify the entire architecture design, and human action equally the starting point for testing the compages prototype.

Although views of "iv plus 1" mentioned above are mostly represented by UML diagrams, in fact, "iv plus i" itself is a kind of universal view model. Marks and tools of drawing are not limited. For engineers, this partially theoretical method may not be directly used in their work, only ane key architecture cartoon idea of "4 plus 1" is very valuable. That is the architecture needs to become through various views for description, while these views are based on viewpoints of different projection stakeholders. Only in this way can architecture descriptions be comprehensive, three-dimensional and objective.

C4 Model

C4 model is an abstraction-commencement compages drawing method, which is likewise inspired by UML and "4 plus 1" view model, merely is relatively simpler and more lightweight. C4 model is easy to be learned and used with just a small set up of abstractions and diagrams.

Definitions, Goals and Key Ideas

C4 model describes a static structure of the software system past abstraction such as containers, components, code, and people. Its core goal is to create maps of code, at diverse levels of details, in the same way every bit Google Maps to zoom in and out of an area. Its most crucial idea is to gradually carve up the static structure of the organization by acme-downwardly algorithm, and depict responsibilities, relationships, and external dependencies of objects at all levels in sequence. In addition to the core hierarchical and static structure view, it besides includes supplementary views such as dynamic view and deployment view.

The effigy on the left shows mapping relationships of abstractions in diverse levels of C4 model. I software organization consists of one to Northward containers, while ane container consists of one to Northward components and one component consists of ane to N code structures. The figure on the right takes a elementary Bound PetClinic as an instance, demonstrating the bureaucracy of a real software system in the C4 model. The top layer is the PetClinic software system, which can exist divide into several containers like databases and web applications. Web applications contain components like ClinicService, which includes components of ClinicService interface, ClinicService implementation, and domain objects such as Owner, Pet, and Visit.

Compages drawing through C4 model is essentially the visualization of above-mentioned abstractions. The specific manner is to create types of structural diagrams from crude ones to detailed ones in sequence, which are Context, Container, Component, and Code (optional). This is also the reason why it is called C4 model.

Level 1: Arrangement Context Diagram

As the first level (L1), context diagrams of the system provide a large picture with the comprehensive view of the organization. The big picture includes the central software system, peripheral users, and other systems with interactions. In that location are 2 key concepts in information technology.

Person: It refers users of the software system, such every bit consumers, operators, arrangement administrators of an online mall arrangement.
Software system: Equally the highest level of abstraction, software system describes the software products that create value for users. Both the software system currently existence designed and other software systems with dependency relationships are included. A software system is usually the responsibility of a unmarried software development team.

When drawing context diagrams of the arrangement, in that location is no need to intendance about any underlying details such as technology stacks and protocols. These diagrams have a large range of audiences, because anyone tin understand and obtain enough information from them. It is true for technical and not-technical personnel, besides as members within and outside the team.

Level 2: Container Diagram

Later on understanding the positioning of the system in the entire IT environment through context diagrams, the next step is to enlarge the framework of the arrangement and see in detail which containers are included. Here please pay plenty attention to the differences between container and docker.

In the C4 model, a container is a unmarried application or data storage. Generally, a container can exist deployed and run independently considering it has independent process space and communicate by IPC mechanism. The container includes Spring Kick microservices, React SPA, mobile App, database, Serverlss role, and Beat script.

The container diagram in the second level (L2) not simply shows how to farther divide responsibilities of the system. It too includes central architecture information such as primary technology pick and advice betwixt containers. This type of diagram is intended for all technical personnel, including architects, developers, O&M personnel, and support professionals.

Level 3: Component Diagram

The next step is to partially zoom in containers in the system and farther split each container into multiple components. In the C4 model, a component is a group of related functions that are encapsulated together through good interface definition. These functions are usually run within the same process space, for instance, a controller in Spring. Controller includes not only main class controllers that ascertain Residue interfaces, but likewise all the related controllers of implementation classes, such every bit Service and Repository.

Similar to container diagrams, component diagrams of the 3rd level (L3) include non simply the division of container components, only besides the responsibility definitions, technologies, and implementation details of each component. Every bit layers deepen and details increase, the audiences range of component diagrams narrows. Target audiences generally only include software architects and developers. For other people, it is not necessary for them to empathize, not mention that they are ordinarily unable to empathize.

Level iv: Code (Optional)

By scaling upwardly the component, we volition run into the detailed information in bottom layer. This is the lawmaking of level 4 (L4). Of course, the so-chosen code hither all the same takes the grade of diagrams such as UML class diagrams and database E/R diagrams. These diagrams show the code construction in classes- or file-level granularity, but they are not the existent code. Even so, code diagrams are also detailed in 99% of architecture description scenarios. On the ane mitt, they are numerous and take high price of cartoon. On the other hand, they are easy to be inverse and have high maintenance costs. Therefore, only important and circuitous components need to utilize this layer for description. If y'all do demand to draw lawmaking diagrams, you lot'd improve requite priority to the automatic ways. For example, many IDEs back up automatic generation of UML grade diagrams.

Supplementary Diagrams: Landscape / Dynamic / Deployment Diagram

In addition to static structure diagrams of each level higher up, the C4 model also proposes a series of supplementary diagrams every bit follows.

System landscape diagram: It has the similar drawing method with the organisation context diagram. The difference between them is that, from the perspective of the enterprises or organizations, the system landscape diagram shows all software systems panoramically, including those not directly related to the current organisation. Information technology also shows related users and system interactions. In other words, it furtherly zooms in the telescopic of the architecture diagram.
Dynamic diagram: As the construction diagram tin just describe the static structural backdrop of a organization, we recommend you utilise communication diagrams or sequence diagrams of UML in the C4 model. These diagrams provide supplementary descriptions for dynamic behaviors of fundamental procedures in the system. In other words, it shows the "combination of dynamic behaviors and static properties".
Deployment diagram: In addition to the lack of dynamic properties, the structure diagram has another limitation. It only describes the abstract logic architecture of the system, but does non describe the specific concrete architecture in actual deployment. Therefore, we recommend you lot use deployment diagrams of UML in the C4 model. They provide supplementary descriptions for mapping relationships between logical nodes (generally referring to containers of L2) and concrete nodes (such as physical machines, virtual machines, Docker containers, and application runtime). In other words, the deployment diagram shows the "combination of virtual and physical architectures".

With the combination of these supplementary diagrams, the C4 model could be a complete architecture drawing method for comprehensively describing all aspects of the software compages in depth.

Arc42

Strictly speaking, arc42 is not an architectural drawing method, merely an architecture document template. Although diagram is a better choice than text in the architecture description as mentioned earlier, you lot nonetheless need to produce a relatively consummate compages document with both texts and diagrams. Arc42 is designed to help you lot better write architecture documents including the near important compages diagram in the compages documents. Multiple core capacity of arc42 introduction are related to the compages diagram, and corresponding cartoon methods are described in detail. Here I will non introduce the arc42 in detail, but briefly introduce similarities and differences of drawing methods betwixt arc42 and C4 model.

Great ideas are ever similar, and arc42 is no exception. The right function of the figure on the left summarizes several core chapters of arc42 that related to drawing.

Chapter iii Context: This affiliate introduces the background and context of the system, and so its drawing idea is most equivalent to organization context diagram (L1) in C4 model.
Affiliate 5 Building block view: This affiliate introduces basic elements of the system. Its guiding idea is similar to the acme-down hierarchical splitting idea in C4 model. The only difference is that arc42 does non stipulate specific levels of splitting, merely provides a splitting direction from "black box" to "white box", if needed.
Chapter 6 Runtime view: It is equivalent to the supplementary runtime diagram in the C4 model.
Chapter 7 Deployment view: Similarly, this is equivalent to the supplementary deployment diagram in the C4 model. However, arc42 emphasizes that the deployment diagram can also exist split up in a pinnacle-down hierarchy like the structure diagram. For more circuitous deployment architectures, hierarchy is actually necessary.

Therefore, in essence, drawing methods advocated in arc42 are equivalent to and uniform with those in C4 model, and they tin exist used together. In practice, we apply arc42 as the architecture document framework, and C4 model for compages drawing.

Other Drawing Methods and Tools

In addition to above methods, many other fantabulous architecture cartoon methods have emerged during decades of vigorous evolution of the software industry. These methods include some universal methods such as SysML, AADL, ArchiMate, and some domain-specific methods such every bit BPMN commonly used in background business modeling scenarios of enterprises. If you are interested in these methods, delight search and explore on your ain.

So far, this chapter has introduced diverse methods of architecture drawing. All the same, in the actual procedure from methods to practices, there is still a crucial pace. That is, what kind of tools should exist selected for drawing? Equally the promoter of digital reform, programmers must fully employ digital tools. I believe that everyone must take nerveless a lot of handy drawing tools in your daily work. Hither, I but recommend two that I apply the most.

draw.io: This is an open-source and on-line drawing software that many people may accept used. For data security reasons, I recommend you employ off-line desktop edition. As a programmer-friendly drawing tool, the biggest advantage of draw.io is its back up for 3rd-party plug-ins. For example, the open up-source c4-draw.io plug-ins could help you draw C4 model compages diagrams in draw.io more conveniently.
PlantUML: As the representative tool in text drawing, PlantUML can exist used to draw various types of UML diagrams, and other diagrams that are applicable to text drawing scenarios, such as the open-source C4-PlantUML extension. In these scenarios, text drawing has many advantages over visual drawing in lightweight, efficiency, versioning, automation, consistency, and easy reuse. Text drawing tools accept been born for a long time. For example, the widely used Graphviz starting time released in 1991. However, information technology is believed that with the awakening of various mod consciousness of Thirty as Code, this kind of Diagram every bit Lawmaking tools will attract more users. By the style, Yuque'south documentation has already supported embedded PlantUML drawing.

Summary of Architecture Drawing Methodology

Information technology is ameliorate to teach people methodology than to introduce methods. Although the word "methodology" has been used widely in enterprises, it does have its value and pregnant.

Methodology is the abstraction of methods in higher dimension, from which detailed methods for solving issues can be derived. Only subsequently understanding the methodology, you tin can reach a thorough understanding and master essential key points of solving bug. You will not be limited by a unmarried specific method, considering any method tin can be used speedily and flexibly, and y'all can become almost the aforementioned event.

Therefore, in the last office of this commodity, I summarize various compages drawing methods and try to extract a full general architecture cartoon methodology. I hope to aid you improve understand principles and ideas of compages drawing. Fifty-fifty though those well-known methods and tools will somewhen be out of appointment, you lot tin nonetheless have it as the transition from one-time ones to new ones. In the by, at that place was UML; at present we have C4 model, and what will at that place be in the future? However, this is not of import, because fifty-fifty if those methods will exist out of engagement, the methodology volition not.

The question is what kind of core methodology is supporting those numerous methods? With "painstaking" efforts for nearly 15 seconds, I finally summed up the following gear up of methodology. Only kidding! Since it contains v interlocking points, simply call it the five rings theory.

Understand Drawing Objectives

The first main indicate of architecture drawing is to have a deep understanding of cartoon objectives. The so-called "take the beginning as the cease" teaches us to motility forward clearly only with the goal. Or otherwise, we may lose our way or fifty-fifty get the opposite upshot. Many of drawing objectives really take been mentioned earlier. Here I'd like to give a brief summarization.

Accuracy: A wrong diagram is worse than no diagram. Even if a diagram is authentic at the kickoff, it still needs to be regularly updated and proofread.
Completion: Cartoon needs to embrace core elements and central data of the architecture, providing a complete architecture blueprint for audiences.
Clarity: It is best to employ legends, such as unlike shapes, colors, line types and arrows when drawing. You also tin add annotations past texts when it is hard to explain only by diagrams.
Consistency: For example, information technology is better to use the aforementioned tick manner to reduce understanding difficulties for audiences in diagrams of the same type. In improver, inconsistency may also cause confusion.
Conciseness: On the footing of coming together above 4 points, information technology is as well necessary to make the diagram more concise. For i matter, it is easier to exist accepted. For another, it is likewise lower in update and maintenance costs.

Identify Audiences and Their Concerns

The second point of compages drawing is to notice out audiences and their concerns. If you tin't notice it, either the effect will be greatly reduced, or it will be difficult for your audiences to understand. Some common audiences and concerns may include equally follows.

Research personnel unremarkably focus on many implementation-related details, such as technical selection, implementation feasibility, and maintainability. Afterwards all, they are the most direct consumers of the compages.
O&M engineers practise not care much near the specific technology implementation in an awarding, merely they care about physical deployment methods, network connectivity, and O&Thousand performance of each application case.
Security professionals only focus on security risks in the system, such as malicious code or permission vulnerabilities. If you lot accept undergone a security review, you should be impressed.
Products promotion staff only intendance about whether the projection can be launched on schedule in most cases. However, they actually don't care about or sympathize other aspects.

Top-down and Layer-past-layer Description

The third signal of architecture cartoon is top-down and layer-by-layer clarification through reasonable application of bureaucracy. Whether information technology is C4 model or arc42 template, hierarchy is securely practical and significantly emphasized. The reason is that it contains ii universal principles.

Divide-and-manage principle: Information technology is the nigh effective way in controlling and dealing with complex systems in the software field. Hierarchical splitting is essentially a divide-and-manage method. By this method, the arrangement is split into multiple relatively independent and low-coupling elements such as subsystems, applications and components according to detailed degrees of different levels.
Pyramid principle: My cadre thought is to present the main point first and then demonstrate information technology with each sub-point in turn in a meridian-downward way. This way of communication is more in line with man thinking logic and easier for audiences to take. In short, information technology focuses on central bespeak. This principle helps audiences focus on cardinal point, instead of throwing out a lot of scattered things for agreement and deducing past their own.

Use Multiple Architectural Views

The 4th point of compages drawing is like to the traditional engineering drawing methodology, which refers to using multiple architectural views to describe the architecture. In engineering science drawing, whatever three-dimensional products, from machine tools to parts, need to be described by at to the lowest degree three views: principal view, top view and left view. As a reflection of the real world, the software arrangement is also multi-dimensional, and information technology is impossible to cover all the primal architecture information with only one view. Fifty-fifty if all this data is forcibly stuffed in one diagram, information technology will certainly be besides complicated to be understood.

In the field of architecture design, architectural view has a special definition. Information technology is a description of i aspect of a system'due south architecture, and each view covers one or more architecture concerns of the stakeholders. The above definition shows that unlike architecture views have different focuses. At the same fourth dimension, other details unrelated to the current view are omitted when describing aspects y'all focus on. This is actually similar to divide-and-manage principle of hierarchical splitting. Architectural view is the dimension decomposition for the consummate system, while the bureaucracy is for a specific view to do top-downwards vertical drill-downward. Both are orthogonal and tin can cooperate with each other. For example, the structure view, the deployment view, and even the dynamic view mentioned above can all be furtherly split in a hierarchical style.

Follow Specifications and All-time Practices

The fifth signal in architecture drawing is an onetime maxim, but information technology is a truth. Follow specifications and best practices. This bespeak is no longer limited to architecture drawing, but has risen to the level of universal methodology in the field of engineering exercise. Every bit stated in the previous chapter, the goal of learning architecture cartoon is to change it from a arts and crafts to an engineering. So, the drawing process of compages certainly should adjust to the engineering thinking.

On the 1 mitt, cartoon needs to follow clear specifications, and bear constraint and guidance on the theoretical level. Thus, the high quality and standardization of processes and products can be ensured.

On the other hand, cartoon also needs to follow best practices in the industry, continuously absorb excellent experience in applied level, and constantly improve cartoon skills of ourselves and the team.

Appendix: Standardized Conceptual Model of Compages Clarification

In fact, special standards, such as ISO, IEC, IEEE 42010:2011, have been established for the architecture description internationally. Many concepts of these standards are mentioned in this article, including stakeholder, concern, view, and viewpoint.

: Alibaba Developer

234 posts | 36 followers
Follow

You may also similar

Comments

: Alibaba Developer

234 posts | 36 followers
Follow