Clean Architecture

JungChihoon·2021년 1월 28일

clean architecture 설계 패턴

개념

목록 보기

2/3

Business Rule & System Architecture

Business Rule?

Business Rule(Logic)은 컴퓨터 프로그램에서 실세계의 규칙에 따라 테이터를 생성/표시/저장/변경하는 부분을 일컫는다.(= domain logic)
System Architecture?

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

여러 다양한 시스템 아키텍쳐들의 목적은 다음 하나의 목적으로 귀결됨.

관심사의 분리

소프트웨어를 계층으로 나누게 되면 관심사를 분리할 수 있다.

1. 프레임워크 독립적
System Architecture는 라이브러리 존재 여부나 프레임워크에 한정적이지 않아 도구로써 사용하는 것이 가능
2. 테스트 용이
Business Rule은 UI, DB, Web Server 등 기타 외부요인과 관계없이 테스트 가능
3. UI 독립적
시스템의 다른부분을 고려하지 않고 UI를 변경 가능
4. Database 독립적
DB 또한 독립적으로 변경할 수 있으며 (SQL,, Mongo 등), 이는 Business Rule에 얽매이지 않음
5. 외부기능 독립적
Business Rule은 외부상황(DB, UI)에 대해서는 아무것도 모름

결론적으로 System Architecture의 목적은 각 계층별 관심사에 따라 독립적으로 분리시켜 응집성을 높이고 결합성을 낮춰 유연성, 확장성을 향상시키는 것이다.(: 수정, 유지보수가 용이함)

이러한 목적으로 Robert C Martin이 제시한 System Architecture가 Clean Architecture이다.

Clean architecture

Domain

Domain 계층은 Business Rules가 존재하는 영역

Infrastructure

Infrastructure 계층은 UI, Database, Web APIs, Frameworks 등이 존재하는 영역

Robert C Martin은 이러한 경계를 두어 각 계층을 분리, 관심사를 분리하는 것이 대부분의 architecture의 공통적인 목표이며 그러기 위해서 의존성 규칙을 지켜야 한다고 말함.

의존성 규칙

모든 소스코드 의존성은 반드시 outer에서 inner로, 저수준에서 고수준 정책을 향해야 한다.

의존성 규칙 참조 : https://velog.io/@jch9537/Dependency

의존성 규칙에 따르면 inner circle에 해당하는 Domain은 outer circle에 해당하는 Infrastructure에 대해서는 아무것도 모른다.
이것은 UI, DB는 Business Rule에 의존하지만 Business Rule은 그렇지 않다는 뜻이다.
따라서 Business Rule의 입장에서는 UI가 웹이든 모바일든, DB가 SQL이든 NoSQL이든에 관계가 없다. 이렇게 분리된 계층 덕에 Infrastructure를 쉽게 변경할 수가 있다.

Clean Architecture

위의 그림을 더 자세히 나타낸 그림이다.

Domain이 Entity, Use Cases로 세분화되었고, Adapter가 생겨 Domain과 Infrastructure사이의 경계를 관리한다.

Entity

애플리케이션에서 핵심적인 기능인 Business Rule들을 담고 있다.
Use Cases

1) 특정 application에 대한 Business Rules이다.
2) Use Cases는 시스템이 어떻게 자동화 될 것인지에 대해서 정의하고 app의 행위를 결정한다.
3) 프로젝트 레벨의 Business Rules(Entity)를 사용하여 Use Cases의 목적을 달성한다.
4) Use Cases는 Entity들에 의존하는 동시에 상호작용을 한다.
5) 이 계층에서는 외부 계층에서 사용할 수 있는 abstract class나 interface들을 정의한다.
Adapters

1) Domain과 Infrastructure사이의 번역기 역할을 수행한다.
2) GUI로부터 input data를 받아 Use Case와 Entity들에게 편리한 형태로 제공한다. 그리고 Use Case와 Entity들의 output data를 가져와 GUI에 표시하거나 DB에 저장하기 편리한 형식으로 data를 제공한다.
3) Adapter는 GUI의 MVC 아키텍쳐를 완전히 내포하며, Presenter, View, Controller가 여기에 속한다.
Infrastructure

1) Infrastructure는 모든 I/O components (UI, DB, frameworks, devices)가 있는 곳이다.
2) I/O components는 변화 될 가능성이 높기 때문에 Domain과는 확실히 분리되어있어 비교적 쉽게 변화하고 component 또한 쉽게 교환될수 있다.
교차 경계

1) Clean architecture를 나타내는 원에서 Adapter에 해당하는Controller와 Presenter가 상위계층인 Use Cases의 경계에서 어떻게 소통하는지를 나타내는 그림이다.

2) 여기서 제어흐름이 Controller > Use Cases > Presenter로 흐르고 있다.
3) 고수준의 Use Cases가 저수준의 Presenter를 참조하고 있는데 이를 해결하기 위해 의존관계 역전의 원칙을 적용해야 한다.
4) 의존관계역전의 원칙 참조 : https://velog.io/@jch9537/Dependency

결론

Clean Architecture는 계층별 관심사를 독립적으로 분리한다.
Clean Architecture는 관심사를 분리하기 위해 의존성 규칙을 따른다.
고수준 계층인 내부 Business Rule(Use Cases, Entity)은 저수준의 계층인 외부 Infrastructure(UI, DB, web, frameworks...)를 알지 못환다.
Adapter는 Domain과 Infrastructure의 경계를 인터페이스를 통해 관리하며 계층간의 데이터를 변환시켜주어 inner > outer로 의존성을 가지도록 한다.