티스토리 뷰
안녕하세요 ! 국산 엘런 입니다 :)
Robert C Martin(Uncle Bob) 형님이 블로그에 기재하시면서 화재가 된 것이 Clean Architecture 입니다.
Clean Architecture 에 대한 소개에 앞서 알아야할 개념 두가지,
Business Rule 과 System Architecture에 대해서 먼저 짚고 넘어가겠습니다.
Business Rule ?
Business Rule(Logic)은 컴퓨터 프로그램에서 실세계의 규칙에 따라 데이터를 생성·표시·저장·변경하는 부분을 일컫는다. (= domain logic)
Business Rule(Logic) 은 유저의 입력(UI) 과 DB 사이에서 발생한 정보 교환을 위한 특정 알고리즘이나 규칙이 정의된 tier입니다.
이는 고객의 요구에 따라 변경될 수 있으며, 그렇기 때문에 별도의 tier에 배치되어야 합니다.
Business Rule(Logic) 에 대한 자세한 정보는 여기를 참고해주세용
System Architecture ?
System Architecture는 시스템의 구조(structure), 행위(behavior), 뷰(views)를 정의하는 개념 모델이다. 시스템의 목적을 달성하기 위해 각 컴포넌트가 어떻게 상호작용하고 정보가 어떻게 교환되는 지를 설명한다.
이미 다양한 시스템 아키텍처들이 나왔지만 결국 그들의 목적은 하나로 귀결됩니다.
관심사의 분리
소프트웨어를 계층으로 나누게 되면 관심사를 분리할 수 있습니다.
이러한 목적을 가진 시스템 아키텍처는 다음과 같은 시스템을 생성하게 됩니다.
-
프레임워크 독립적
System Architecture는 라이브러리 존재 여부나 프레임워크에 한정적이지 않아 도구로써 사용하는 것이 가능합니다.
-
테스트 용이
Business Rule은 UI, DB, Web Server 등 기타 외부 요인과 관계없이 테스트 가능합니다.
-
UI 독립적
시스템의 다른 부분을 고려하지 않고 UI를 변경할 수 있습니다.
-
Database 독립적
DB 또한 독립적으로 변경할 수 있으며 (SQL, Mongo, CouchDB 등), 이는 Buiness Rule에 얽매이지 않습니다.
-
외부 기능 독립적
Business Rule은 외부 상황(DB, UI)에 대해서 아무것도 모릅니다.
Uncle Bob은 이러한 특징을 가지는 Architecture 들에 대한 총 정리(?) 느낌으로
Clean Architecture를 내세웠습니다.
Clean Architecture
먼저 간단한 그림부터 살펴보겠습니다.
Domain
Domain Layer 는 Business Rules 가 존재하는 영역입니다.
번역앱은 번역을 하고 쇼핑몰 앱은 물건을 팝니다.
이렇듯 비즈니스의 본질은 쉽게 바뀌지 않으므로 Business Rule은 잘 변하지 않는 안정된 영역입니다.
Infrastructure
Infrastructure Layer 는 UI, Database, web APIs, Frameworks 등이 존재하는 영역입니다.
이는 Domain 에 비하여 자주, 쉽게 바뀔 수 있습니다. 예를 들어, UI Button 의 형태 (UI) 는 쉽게 바뀔 수 있지만 대출 계산 방법 (Business Rule) 은 그렇지가 않습니다.
Uncle Bob 은 이렇게 경계를 두어 각 Layer을 분리하고, 관심사를 분리하는 규칙을
의존성 규칙(Dependency Rule) 으로 설명하였습니다.
Dependency Rule
모든 소스코드 의존성은 반드시 outer에서 inner로, 고수준 정책을 향해야 한다.
Dependency Rule은 Business Logic 을 담당하는 코드들이 DB 또는 Web같이 구체적인 세부사항에 의존하지 않고 독립적으로 실행되야 한다는 규칙입니다.
그리고 이러한 의존성 규칙을 지키기 위해서는 "What data crosses the boundaries", "Crossing boundaries" 와 같은 상황에 대해서 고려해야하는데, 이는 뒤에서 살펴보도록 하겠습니다.
다시 이 그림으로 돌아와 보겠습니다.
Dependency Rule 에 따르면
inner circle 에 해당하는 Domain 은 outer circle 에 해당하는 Infrastructure 에 대해서 아무것도 모릅니다.
이는 UI, DB 는 Business Rule에 의존하지만 Business Rule은 그렇지 않다는 것입니다.
이는 마치 플러그인 처럼
UI가 웹이건 모바일이건, DB가 SQL 이건 NoSQL 이건 관계없이 Business Rule 입장에서는 아무런 상관이 없습니다.
이렇게 분리된 Layer 덕에 Infrastructure 를 쉽게 변경할 수가 있습니다.
이제 위의 그림을 더 자세히 들여다 보겠습니다.
Domain 이 Entities, Use Cases로 세분화 되었고, Adatper 가 새로 생겨 Domain 과 Infrastructure 사이의 경계를 관리합니다.
이 그림 또한 마찬가지로 Dependency Rule 에 따라 작동하여 outer 에서 inner 로 의존성을 가지게 됩니다.
이제 세분화된 각 레이어에 대해서 알아보겠습니다.
Entity
Entity 는 애플리케이션에서 핵심적인 기능인 Business Rule 들을 담고 있습니다.
이는 대규모 프로젝트 내의 다양한 애플리케이션에서 사용될 수도 있습니다. (애플리케이션에 종속 x)
이게 무슨 말이냐면...
OOP 관점에서 보았을 때
Entity 는 class 내의 method 들의 그룹으로 볼 수 있습니다.
대출 이자가 10% 라는 규칙을 가진 은행이 있다고 가정해 보겠습니다.
지불해야 하는 이자를 손으로 계산하던 컴퓨터로 하던 대출 이자가 10% 라는 사실은 변하지 않을 것입니다.
...
대출 이자 10% 라는 규칙(Business Rule)은 외부 상황(outer layer)을 전혀 모릅니다.
즉, Entity 들은 outer layer 들에 속한 다른 class 나 component 들에 전혀 모르고 신경쓰지 않아도 됩니다.
Use cases
Use cases 는 특정 application에 대한 Business Rules입니다.
Use cases는 시스템이 어떻게 자동화 될 것인지 대해서 정의하고 app 의 행위를 결정합니다.
다시 말해, 프로젝트 레벨의 Business Rules(Entiies) 을 사용하여 Use cases 의 목적을 달성합니다.
다음 예시는 Use cases 를 위한 특정 application 에 대한 Business Rule 의 목록입니다.
Gather Info for New Loan Input: Name, Address, Birthdate, etc. Output: Same info + credit score Rules: 1. Validate name 2. Validate address, etc. 3. Get credit score 4. If credit score < 500 activate Denial 5. Else create Customer (entity) and activate Loan Estimation
Use cases 는 Entities 에 의존하는 동시에 상호작용 합니다. 물론 outer layer 에 대해서는 아는 게 없습니다.
대출이 web page, iphone 어디에서 이뤄지던, data가 cloud, sqlite 어디에 저장되건 Use cases는 관심이 없습니다.
다만 이 계층에서는 outer layer 에서 사용할 수 있는 abstract classes 나 interfaces를 정의합니다.
Adapters
Adapters 는 domain 과 infrastructure 사이의 번역기 역할을 수행합니다.
예를 들어, GUI 로부터 input data 를 받아 Use cases와 Entites 에게 편리한 형태로 repackage 합니다.
그리고 Uses cases와 Entities 의 ouput 을 가져와 GUI 에 표시하거나 DB 에 저장하기 편리한 형식으로 repackage 합니다.
Adapters 는 GUI 의 MVC 아키텍처를 완전히 내포하며, Presenter, View, Controller 가 모두 여기에 속합니다.
Infrastructure
Infrastructure 는 모든 I/O components (UI, DB, frameworks, devices) 가 있는 곳입니다.
이는 변화될 가능성이 매우 높기 때문에 stable 한 domain 과는 확실히 분리가 되어있고, 그렇기 때문에 비교적 쉽게 변화되고 component 또한 쉽게 교환됩니다.
이렇게 각 Layer 의 역할에 대해서 살펴 보았습니다.
그렇다면 Layer 의 경계에서 어떤식으로 데이터가 오고 가는지에 대해서 고민을 해보겠습니다.
교차 경계
위의 그림의 오른쪽 하단을 보면 아래의 다이어그램을 볼 수 있습니다.
위 다이어그램은 원의 경계가 어떤식으로 교차하는지 보여주는 예시입니다.
더 자세히 말하자면, Adapter 에 해당하는 Presenter 와 Controller 가 상위 계층인 Use cases 와 어떻게 소통하는지 나타내고 있습니다.
하지만 여기서 의문이 하나 생기게 됩니다.
제어의 흐름 (Flow of Control) 을 보면 Controller → Use cases → Presenter 로 흘러감을 확인할 수가 있습니다.
고수준의 Use cases 가 저수준의 Presenter 를 참조하고 있는 상황입니다 .. !
이 문제를 해결하기 위한 것이 의존 관계 역전의 원칙(Dependency Inversion Priciple)인데,
아래에서 다시 살펴보도록 하겠습니다.
...
지금까지 실컷 시용한 Dependency Rule 이지만 이를 지키기 위해서는
위에서는 잠시 언급했듯이, 아래 두 상황을 고려해야 합니다.
What data crosses the boundaries
의존성 규칙을 지키기 위해서는 단순하고, 고립된 형태의 데이터 구조를 사용해야 합니다.
DB의 형식의 데이터 구조 또는 Framework에 종속적인 데이터 구조가 사용되게 된다면, 이러한 저수준의 데이터 형식을 고수준에서 알아야 하기 때문에 의존성 규칙을 위반하게 됩니다.
Crossing boundaries
두 번쨰로는 crossing boundaries 입니다.
이는 제어의 흐름은 원의 내부에서 외부로 향할 수 있는데, 이는 의존성 규칙에 위배되므로 의존성 역전의 원칙(DIP)을 이용하여 해결해야 한다는 이야기 입니다.
즉 고수준에서 저수준에 직접 참조하게 될때 Interface를 하나 둠으로써, 저수준의 세부사항을 알 필요 없고 변동사항에도 영향을 받지 않게 됩니다.
...
Conclusion
Clean Architecture 는 의존성 규칙을 따름으로써 관심사가 분리되고
본질적으로 테스트하기 쉬운 시스템을 만들 수 있고 의존성 규칙이 가져오는 이점을 가져올 수 있다고 정의내립니다.
같은 상황과 이유로 변경되는 Class 들은 components 로 묶입니다.
Business Rule 은 stable한 components 로, 변경되기 쉬운 외부의 Infrastructure components (UI, DB, web, frameworks ..) 를 알지 못합니다.
이 두 component Layer 간의 경계는 Adapter 인터페이스를 통해 관리되며,
Adpater 는 Layer 간의 데이터를 편한 형태로 변환시켜주고 더 stable 한 inner components 로 의존성을 가지도록 합니다.
...
이렇게 Clean Architecture 를 향한 긴 여정을 마쳤습니다...
처음에 감이 오지 않아 여러 블로그를 참고하였고,
정말 많이 배웠습니다.
다른 분들도 도움이 되셨기를 바라면서
...
그럼 20000.
본 포스팅은 Uncle Bob's blog, PUSHER, Investopedia, 우아한형제들 기술블로그를 참고하였습니다.