관심사 분리
Clean Architecture는 Robert C Martin(Uncle Bob)이 블로그에 기재하면서 생겨난 개념이다.
다양한 아키텍처가 있지만 대부분 아키텍처의 공통적인 목표는 계층을 분리하여 관심사의 분리를 하는 것이다.
대략적인 구조는 다음과 같다.
Infrastructure
Infrastructure Layer 는 UI, Database, web APIs, Frameworks 등이 존재하는 영역이다.
이는 Domain에 비하여 자주, 쉽게 바뀔 수 있기 때문에 Domain과는 확실하게 분리가 되어야한다.
Domain
Domain Layer 는 Business Rules가 존재하는 영역이다.
포스팅하기, 사진올리기 등 기술과는 상관없는 비지니스와 연관되어 있는 로직이다. 잘 변하지 않는 안정된 영역이다.
더 세분화하면 Infrastructure - Adaptors - Use Cases - Entities 로 나눌 수 있다.
Use cases와 Entities가 Domain영역에 해당한다.
Use case
로그인하기, 업무처리하기, 포스팅하기, 사진업로드하기와 같이 동사로 표현되는 비지니스 로직을 말한다. Use cases는 Entity에 의존하는 동시에 상호작용한다.
Entity
Entity는 비즈니스 로직을 캡슐화한 것으로 가장 일반적이면서도 고수준의 규칙을 캡슐화한 모듈이다.
Adaptor
domain 과 infrastructure 사이의 번역기 역할을 수행한다. presenters, repositories에 해당한다. GUI 로부터 input data 를 받아 Use cases와 Entites 에게 편리한 형태로 가공한다. Use cases와 Entities 의 ouput 을 가져와 GUI 에 표시하거나 DB 에 저장하기 편리한 형식으로 가공한다.
의존성 규칙(Dependency Rule)
경계를 두어 각 Layer을 분리하고, 관심사를 분리하는 규칙을 의존성 규칙(Dependency Rule) 으로 설명할 수 있다.
"모든 소스코드 의존성은 반드시 outer에서 inner로, 고수준 정책을 향해야 한다."
inner로 갈수록 고수준에 해당하고, 고수준과 저수준은 추상화의 정도에 따라 분류되는데 추상화가 많이 되어 있을수록 고수준이다.
inner layer(고수준)는 outer layer(저수준)에 대해 몰라야한다.
즉, domain(usecase와 entity)은 infrastructure(UI, DB, Framework)에 의존하지 않고 독립적으로 실행되야 한다는 규칙이다. UI, DB, Framework는 Business logic을 의존하지만 Business logic은 infrastructure에 대해 몰라야한다. UI가 웹이건 모바일이건, DB가 SQL 이건 NoSQL 이건 관계없이 Business Rule 입장에서는 아무런 상관이 없다.
💡️ 추상화
인터페이스에 의존하고 구체적인 구현에는 의존하지 않는 것이다. 함수를 기본적인 추상화 방법으로 사용한다. 함수 이름을 통해서 구체적으로 하는 일을 추상화해서 나타낸다. 예를 들어 sendMessage라는 함수가 있으면 이름을 보고 메시지를 보내는 로직이라는 것은 알지만 구체적으로 그 내용에 대해서는 알지 못한다. 이처럼 그 내용은 알지 못하더라도 어떤 일을 하는지는 알고 사용한다. 그것만으로도 구현하는데 충분하기 때문이다.
의존 관계 역전의 원칙(Dependency Inversion Priciple)
하지만 고수준(Use cases)이 저수준(Presenter)을 참조하는 경우가 있는데 이런경우에는 의존 관계 역전의 원칙(Dependency Inversion Priciple)에 의해 해결될 수 있다.
Use case는 Output port라는 인터페이스를 둔다. 그리고 Presenter는 이 Output port 인터페이스를 구현한다. 직접 Presenter는 Use case에 직접 접근하는 것이 아니라 Output port라는 인터페이스를 통해 접근하는 것이다.
이를 통해 고수준(Use cases)은 저수준(Presenter)의 세부사항을 알 필요 없고 변동사항에도 영향을 받지 않게 된다.
📌️ 결과적으로 관심사 분리를 적용한 아키텍처를 도입하게되면 라이브러리, 프레임워크의 종류에 관계없이 사용할 수 있다. Business logic은 UI, DB, Web server 등 기타 외부 요인과 관계없이 테스트가 가능하고 UI, DB는 다른 부분을 고려하지 않고 독립적으로 변경이 가능한 장점이 있다.
