의존성 역전 법칙(3) — Traditional Layered Architecture, Clean Architecture
3. 계층구조와 의존성 역전
전통적인 계층구조
OOP의 원칙에 따라 관심사를 분리하여 각 객체(레이어, 모듈)가 하나의 중요한 책임을 갖도록 구조로 나타낸것입니다.
Presentation — Domain or Service — Data 의 계층 구조로, 순차적으로 제어의 흐름이 진행되며, 가장 하단의 Data- Layer가 제어의 주체가 되는 구조입니다.
- UI(Presentation-Layer)에서 Input이 발생하면
- UseCase, Interacter(Domain-Layer)에서 비즈니스 로직을 처리한 후,
- 데이터를 Local DB, Network Server(Data-Layer)에 저장하거나 불러와서
- 다시 UseCase, Interacter(Domain-Layer)에서 데이터를 가공하여
- UI(Presentation-Layer)에서 Output으로 보여주게 됩니다.
앞서 객체간의 의존성을 살펴봤던 것 처럼, 이러한 구조라면 Domain-Layer의 비즈니스 로직이 데이터 로직에 의존하게 됩니다.
우리가 집중해야할, 그리고 가장 중요한 Layer는 바로 Domain, Service- Layer입니다.
Data-Layer를 의존하게 되는 구조라면 로컬데이터의 수정이나 서버사이드의 변경으로, Domain이 크게 영향을 받게 됩니다. 그리고 UseCase는 크게 달라지는 것이 없는데 UI나 DB의 변경이 자주 발생한다면, 그때마다 Domain의 수정이 필수 불가결할 것입니다.
이러한 구조를 개선하기 위해 클린아키텍처를 채택할 수 있고 제가 생각하는 클린아키텍처의 중요한 부분 중 하나가 의존성 역전으로 제어의 흐름을 역전하는 것입니다.
클린아키텍처
클린아키텍처를 검색하면 오른쪽과 같은 원형 구조가 많이 보입니다. 이를 기존의 레이어드 구조를 통해 이해해 보겠습니다.
우리가 집중해야 할 도메인 레이어를 제어의 주체로 만들어 비즈니스 로직에 집중하고, Entity(비즈니스 로직에 사용되는 객체들)을 중심으로 위치시켜 가장 외부의 영향을 덜 받고 다른 객체에 의존하지 않는 상태로 만들어진 구조입니다.
즉, 기존의 레이어드 구조에서 Presentation ➡️ Domain or Service ⬅️ Data로 제어의 방향을 역전시키고 의존성을 역전시킨 구조입니다.
지금까지 살펴본 인터페이스 또는 객체를 사용한 의존성 역전을 도메인과 데이터 레이어 사이에 활용한다면 다음과 같이 적용할 수 있을 것입니다.
