CS & SW & IT 용어

[Clean Architecture]란 무엇인가

Haksae 2022. 2. 27. 23:19
참고문서
1. https://blog.coderifleman.com/2017/12/18/the-clean-architecture/  / 로버트 C.마틴의 The Clean Architecture를 한국어로 번역한 글
2. https://k-elon.tistory.com/38 / 설명 글
3. https://dailyheumsi.tistory.com/239

 

1. system architecture?

시스템 아키텍처는 시스템의 구조(structure), 행위(behavior), 뷰(views)를 정의하는 개념 모델이다. 시스템의 목적을 달성하기 위한 각 컴포넌트가 어떻게 상호작용하고 정보가 어떻게 교환되는지를 설명한다.

→ 시스템 아키텍쳐들의 “관심사의 분리(separation of concerns)” 라는 하나의 목적으로 귀결된다.

→ 시스템 아키텍처는 스프트웨어 계층을 나눔으로써 관심사를 분리한다.

  • 시스템 아키텍처의 목적 (왜 나누는가?)
    • 아키텍처의 목적은 시스템을 쉽게 이해, 개발, 유지보수, 배포할 수 있게 하여, 시스템의 수명과 관련된 비용을 최소화하고, 프로그래머의 생산성을 최대화하는 것이다.
  • 계층을 어떻게 나누는가?
    • Policy(정책)과 Detail(세부사항)으로 나눈다.
    • 정책 요소는 모든 업무 규칙(Business Rules)과 업무 절차(Procedures)를 구체화한다.
    •  

1. 프레임워크 독립적

  • System Architecture는 라이브러리 존재 여부나 프레임워크에 한정적이지 않아 도구로써 사용하는 것이 가능하다

2. 테스트 용이

  • Business Rule은 UI, DB, Web Server 등 기타 외부 요인과 관계없이 테스트 가능하다.

3. UI 독립적

  • 시스템의 다른 부분을 고려하지 않고 UI를 변경할 수 있다.

4. Database 독립적

  • DB 또한 독립적으로 변경할 수 있으며 (SQL, Mongo, CouchDB 등), 이는 Buiness Rule에 얽매이지 않는다.

5. 외부 기능 독립적

  • Business Rule은 외부 상황(DB, UI)에 대해서 아무것도 모른다.

 

2. Domain & Infrastructure

 

System Architecture을 크게 도식화하면 다음과 같다.

1) Domain

Domain Layer는 Business Rules가 존재하는 영역이다.

비지니스의 본질은 쉽게 바뀌지 않으므로 Business Rule(Domain)은 잘 변하지 않는 영역이다.

 

2) Infrastructure

Infrastructure Layersms UI, DB, web APIs, Frameworks 등이 존재하는 영역으로서, Domain인에 비해서 자주 바뀔 수 있는 영역이다.

 

3) Dependency Rule

Uncle Bob은 이렇게 경계를 두어 각 layer를 분리하고, 관심사를 분리하는 규칙을 의존성 규칙(Dependency Rule)으로 설명했다.

Dependency Rule은 Infrastructure는 Domain에 의존하지만, Business Logic을 담당하는 코드들이 Infrastructure의 세부사항에 의존하지 않고 독립적으로 실행되어야 한다는 규칙이다. 

즉 소스코드의 의존성을 변하지 않는 Domain에 두어야한다는 것이다.

 

3. Clean Architecture

좋은 아키텍처는 중요한 것과 중요하지 않은 것을 구분하고, 중요하지 않은 것에 의존하지 않도록 잘 분리하여 설계한다.

  • 위의 Dependency Rule에 근거하여 Uncle Bob이 주장한 "The Clean Architecture"의 도식을 살펴보면,
    Domain이 Entities, Use Cases로 세분화 되었고, Adatper가 새로 생겨 Domain과 Infrastructure 사이의 경계를 관리한다.
  • 그리고 마찬가지로 Dependency Rules에 따라 outer에서 inner로 의존성을 가지게된다.
  • 안쪽에서 바깥쪽으로 갈수록 "덜 중요한", "세부사항인" 영역이다.

 

1) Entity

  • 핵심 업무 규칙을 캡슐화한다. 애플리케이션에서 핵심적인 기능인 Business Rule들을 담고 있다.
  • 가장 변하지 않고, 외부로부터 영향을 받지 않는 영역이다.
  • 메서드를 가지는 객체거나 일련의 데이터 구조와 함수의 집합일 수 있다.

2) Use Case

  • 유즈 케이스는 특정 어플리케이션에 대한 비지니스 룰이다.
  • 시스템이 어떻게 자동화도리 것인지에 대해서 정의하고 app의 행위를 결정한다.
  • 엔티티와 상호작용하여 들어오고 나가는 데이터 흐름을 조정하고 조작한다. 

3) Adapters

  • Domain과 Infrastructure 사이의 번역기 역할을 수행한다.
  • 유즈 케이스와 엔티티의 output을 가져와 GUI에 표시하거나 DB에 저장하기 편리한 형식의 repackage 한다.
  • Adapters는 GUI의 MVC 아키텍처를 완전히 내포하며, Presenter, View, controller가 모두 여기에 속한다.

 

4) Infrastructure

  • 모든 I/O components (UI, DB, Frameworks, Devices)가 있는 곳이다.
  • 변화될 가능성이 매우 높기 때문에 안정적인 도메인과는 확실히 분리 되어 있다.

 

클린 아키텍처의 가장 핵심적인 원칙은 바로 의존성 방향에 있다.
의존성 방향은 항상 바깥쪽 원에서 안쪽 원으로 향해야한다.
의존성 규칙을 따름으로써 관심사가 분리되고, 본질적으로 테스트하기 쉬운 시스템을 만들어낸다.