# C4 model introduce

## how to use

### install java

### install graphviz

```sh
brew install graphviz
```

install vscode plugin `PlantUML`

[https://marketplace.visualstudio.com/items?itemName=jebbs.plantuml](https://marketplace.visualstudio.com/items?itemName=jebbs.plantuml)

### create diagram

[https://github.com/plantuml-stdlib/C4-PlantUML](https://github.com/plantuml-stdlib/C4-PlantUML)

```plantuml
@startuml C4_Elements
!include https://raw.githubusercontent.com/plantuml-stdlib/C4-PlantUML/master/C4_Container.puml

Person(personAlias, "Label", "Optional Description")
Container(containerAlias, "Label", "Technology", "Optional Description")
System(systemAlias, "Label", "Optional Description")

Rel(personAlias, containerAlias, "Label", "Optional Technology")
@enduml
```

![](https://3379277180-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MaoWGMVdC3ztoOAzHPq%2Fuploads%2Fgit-blob-291cb58d28b31a223baaa45ea5e1c74abc8d5c34%2F2022-08-11-16-52-33.png?alt=media)

이런 그림이 나온다.

```plantuml
@startuml Basic Sample
!include https://raw.githubusercontent.com/plantuml-stdlib/C4-PlantUML/master/C4_Container.puml

Person(admin, "Administrator")
System_Boundary(c1, "Sample System") {
    Container(web_app, "Web Application", "C#, ASP.NET Core 2.1 MVC", "Allows users to compare multiple Twitter timelines")
}
System(twitter, "Twitter")

Rel(admin, web_app, "Uses", "HTTPS")
Rel(web_app, twitter, "Gets tweets from", "HTTPS")
@enduml
```

### code snippet

[https://github.com/plantuml-stdlib/C4-PlantUML/blob/master/.vscode/C4.code-snippets](https://github.com/plantuml-stdlib/C4-PlantUML/blob/master/.vscode/C4.code-snippets)

이걸 다운받아서 vscode에 연결해준다.

나는 현재 프로젝트에만 사용하려고 .vscode/C4.code-snippets에 넣어주었다.

![](https://3379277180-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MaoWGMVdC3ztoOAzHPq%2Fuploads%2Fgit-blob-4b19bda73e15350387dc58733b45e28ee0751411%2F2022-08-19-07-55-42.png?alt=media)

## 개념

[https://modeling.com/](https://modeling.com/)

4가지 관점의 그림이 있다.

* System Context
* Container
* Component
* Code

![](https://modeling.com/img/c4-overview.png)

## Level

* 서로 다른 관심을 가진 다이어그램 및 문서에 대한 다양한 청중이 있습니다.
* 소프트웨어 아키텍처 다이어그램을 그릴 때 소프트웨어 개발자처럼 생각하십시오.
* 공통된 추상화 집합이 공통 표기법보다 더 중요합니다.
* 소프트웨어 시스템은 하나 이상의 코드 요소에 의해 차례로 구현되는 하나 이상의 구성 요소를 각각 포함하는 하나 이상의 컨테이너로 구성됩니다.
  * ![](https://modeling.com/img/abstractions.png)

### Level 1: System Context Diagram

A System Context diagram provides a starting point, showing how the software system in scope fits into the world around it.

System Context diagram은 범위의 소프트웨어 시스템이 주변 세계에 어떻게 맞는지 보여주는 시작점을 제공합니다.

![](https://modeling.com/img/bigbankplc-SystemContext.png)

### Level 2: Container Diagram

A Container diagram zooms into the software system in scope, showing the high-level technical building blocks.

Container diagram은 범위 내에서 소프트웨어 시스템을 확대하여 높은 수준의 기술 구성 요소를 보여줍니다.

![](https://modeling.com/img/bigbankplc-Containers.png)

### Level 3: Component Diagram

A Component diagram zooms into an individual container, showing the components inside it.

Component diagram은 개별 컨테이너를 확대하여 그 안의 구성 요소를 표시합니다.

![](https://modeling.com/img/bigbankplc-Components.png)

### Level 4: Code Diagram

A code (e.g. UML class) diagram can be used to zoom into an individual component, showing how that component is implemented.

code diagram을 사용하여 개별 구성 요소를 확대하여 해당 구성 요소가 구현되는 방법을 표시할 수 있습니다.

그리기를 추천하지 않으며 자동으로 코드에서 생성하는걸 추천합니다.

![](https://modeling.com/img/bigbankplc-Classes.png)

## misc

### titles

short and meaningful, include the diagram type, numbered if diaram order is important; for example:

짧고 의미 있는 다이어그램 유형을 포함 예를 들어:

```
system context diagram for finalcial risk system
[system Context] Financial Risk System
```

다이어그램 순서가 중요한 경우 번호가 매겨집니다.

### layout

sticky notes and indexs card( e.g crc cards) make a great substitute for hand-drawn boxes, especially if you dont have a whiteboard

스티커 메모 및 색인 카드(예: crc 카드)가 손으로 그린 상자를 대신할 수 있습니다.

### visual consistency

try to be consistent with notation and element positioning across diagrams

다이어그램 전체에서 표기법 및 요소 위치와 일관성을 유지하십시오.

### acronyms(줄임말)

매우 주의하자.

be ware of using acronyms, especially those related to the business/domain that you work in

특히 당신이 일하는 비즈니스/도메인과 관련된 줄임말을 사용하십시요. 새로 조인하는 사람은 바로 이해할수 있습니다.

### element

start with simple boxes containing the element name, type, technology (if appropriate) and a description/responsibilities

요소 이름, 유형, 기술(해당되는 경우) 및 설명/책임이 포함된 간단한 상자로 시작합니다.

### 박스들 표시

![](https://3379277180-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MaoWGMVdC3ztoOAzHPq%2Fuploads%2Fgit-blob-9e2821e0af9e6611b4453c995720816037bc30f2%2F2022-08-19-06-42-23.png?alt=media)

왼쪽처럼하지말고 오른쪽처럼 자세한 내용을 다이어그램에 쓰자.

### lines

favour uni-directional lines showing the most important dependencies or data flow with an annotation to be explicit about the purpose of the lines and direction

가장 중요한 종속성 또는 데이터 흐름을 보여주는 단방향 라인을 선호하며 라인과 방향의 목적을 명시하는 주석을 사용합니다.

summarise the intent of the relationship

관계의 의도 요약

![](https://3379277180-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MaoWGMVdC3ztoOAzHPq%2Fuploads%2Fgit-blob-9a7a72576e92f26a184bf58f680c5db5077a9fc8%2F2022-08-19-06-45-30.png?alt=media)

summarise, yet be specific

요약하되 구체적으로

![](https://3379277180-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MaoWGMVdC3ztoOAzHPq%2Fuploads%2Fgit-blob-5524e7df23a568191ecec53ff8efaef1bd390588%2F2022-08-19-06-46-17.png?alt=media)

show both directions when the intents are differnt

의도가 다른 경우 양방향 표시

![](https://3379277180-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MaoWGMVdC3ztoOAzHPq%2Fuploads%2Fgit-blob-bac5964ec762b148e3567c2e1d83e90498114de6%2F2022-08-19-06-46-40.png?alt=media)

### beware of hiding the true story

![](https://3379277180-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MaoWGMVdC3ztoOAzHPq%2Fuploads%2Fgit-blob-3694061da9d7b13df61c51963a650a0e71e63ec6%2F2022-08-19-06-51-36.png?alt=media)

이런그림이면 맞는 내용이기는 하나 중요한 내용을 숨길수 있습니다.

![](https://3379277180-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MaoWGMVdC3ztoOAzHPq%2Fuploads%2Fgit-blob-78691feb49fecfaec9df0b57ec6128772c2d11a6%2F2022-08-19-06-52-08.png?alt=media)

이렇게 그리면 좀더 명확해집니다.

#### add more word to make the intent explicit

요약을 더 많은 단어로 표현하십시오.

#### key and legend

explain shapes, line styles, colours, borders, acronyms , etc even if you notations seems obvious

표기법이 분명해 보이더라도 모양, 선 스타일, 색상, 테두리, 약어 등을 설명하십시오.

동기 실선 비동기는 점선 등으로 할수 있습니다. 컬러는 색맹을 고려하기 바랍니다.

use shape,colour and size to complement a diagram the already make sense

이미 의미가 있는 다이어그램을 보완하기 위해 모양, 색상 및 크기를 사용합니다.

#### icon

use icons to supplement text, not replace it

아이콘을 사용하여 텍스트를 대체하지 않고 보충하십시오.

increase the readability of software architecture diagrams, so they can stand alone

소프트웨어 아키텍처 다이어그램의 가독성을 높여 독립적으로 사용할 수 있습니다.

아이콘을 추가하여 이해를 도울수 있습니다.

![](https://3379277180-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MaoWGMVdC3ztoOAzHPq%2Fuploads%2Fgit-blob-cec0363d790af507cccad40900b2021ef15add61%2F2022-08-19-07-01-49.png?alt=media)

any narrative should complement the diagram rather than explain it

어떤 보충 문서든 다이어그램을 설명하기보다 보완해야 합니다.

#### notation check list

[https://modeling.com/review/](https://modeling.com/review/) 여기서 해볼수 있다. 아래에서 설명

#### abstractions first, notation second

첫 번째는 추상화

두 번째가 표기법

![](https://3379277180-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MaoWGMVdC3ztoOAzHPq%2Fuploads%2Fgit-blob-5f105602912b106e9cafb5fddb0f2f7bd576a530%2F2022-08-19-07-05-40.png?alt=media)

ensure that your team has a ubiqutous language to describe software architecture

팀이 소프트웨어 아키텍처를 설명하는 유비쿼터스 언어를 가지고 있는지 확인하십시오.

유비쿼터스 컴퓨팅이란 '(신은)어디에나 널리 존재한다'는 라틴어 ubiquitarius의 영어식 변형 'Ubiquitous'와 컴퓨팅이 결합된 단어로 '언제 어디서든 어떤 기기를 통해서도 컴퓨팅할 수 있는 것'을 의미한다.

## review

### General

도표에 제목이 있습니까?

다이어그램 유형이 무엇인지 이해합니까?

다이어그램 범위가 무엇인지 이해합니까?

다이어그램에 키/범례가 있습니까?

### Elements

모든 요소에 이름이 있습니까?

모든 요소의 유형을 이해합니까? (예: 추상화 수준, 예: 소프트웨어 시스템, 컨테이너 등)

모든 요소가 무엇을 하는지 이해합니까?

해당되는 경우 모든 요소와 관련된 기술 선택 사항을 이해하고 있습니까?

사용된 모든 약어와 약어의 의미를 이해합니까?

사용된 모든 색상의 의미를 이해합니까?

사용된 모든 모양의 의미를 이해합니까?

사용된 모든 아이콘의 의미를 이해합니까?

사용된 모든 테두리 스타일의 의미를 이해하고 있습니까? (예: 실선, 점선 등)

사용된 모든 요소 크기의 의미를 이해합니까? (예: 작은 상자와 큰 상자)

### 관계

모든 행에 해당 관계의 의도를 설명하는 레이블이 있습니까?

해당되는 경우 모든 관계와 관련된 기술 선택을 이해하고 있습니까? (예: 프로세스 간 통신을 위한 프로토콜)

사용된 모든 약어와 약어의 의미를 이해합니까?

사용된 모든 색상의 의미를 이해합니까?

사용된 모든 화살촉의 의미를 이해합니까?

사용된 모든 선 스타일의 의미를 이해합니까? (예: 실선, 점선 등)
