10분 테코톡 누누, 다즐의 클린 아키텍처 를 정리한 글입니다.
레이어드 아키텍처
관심사가 같은 코드를 계층으로 그룹화
client -(요청)->
Presentation Layer -(비즈니스 처리 요청)->
Application Layer -(비즈니스 처리에 필요한 데이터 요청)->
Persistence Layer
Presentation, Application, Persistence 순으로 의존성이 발생
그로인해 상위레이어가 하위레이어를 알 수 있음에
하위레이어의 변경시 상위레이어에 영향을 미치는 상황을 만듬
----> 의존성이 생겼다 !
- 코드 변경이 어려워짐
- 테스트 어려워짐
ex) Application의 로직 테스트를 위해 데이터와 함께 테스트 해야함.
- 필요에따라 계층을 추가해서 사용
- 계층화에 따른 분리된 책임
- 데이터베이스 주도 설계가 될 수 있음
클린 아키텍처
의존성 역전을 위해 도메인이 중심
- 핵심 규칙을 담고있는 도메인이 중심
- 도메인이 세부사항에 의존하지 않음
Entity와 use Case가 있는 계층
비즈니스 로직을 캡쳐한 계층이며, 외부 요소에 대해서 절대로 알면 안됨!
외부 요소가 있는 계층
어떤 DB, 프레임워크 를 사용하는지 등..
총 4개의 레이어로 구성
- Entity Layer
- 가장 핵심적인 비즈니스 로직, 규칙을 담고있음
- 대부분의 프로젝트에서 도메인 패키지에 들어있는 것들
- 외부의 요소들에 대한 어떠한 의존성도 가지고있으면 안됨
- Use Case Layer
- 비즈니스 로직 포함
- Repository 에서 객체를 받아와 특정한 행위, 업데이트 처리
- Adapter Layer
- 데이터를 Use Case에서 사용하는 형태로 변환
- 외부에서 사용하는 형태를 외부에 적합한 형태로 변환
- Infrastructure Layer
- DB, 프레임워크 같은 외부와 통신 작업
헥사고날 아키텍처
외부 요소와 핵심 비즈니스로직이 소통할 때 포트를 사용해 간접적으로 통신
- 도메인 모델에 관심을 가짐
- 포트와 어댑터를 구성하고 관리하는데 복잡성이 따름
- 도메인에 라이브러리를 직접 활용하기 어려워 라이브러리에 특화된 기능을 사용하기 어려울 수 있음
POJO로 이루어진 Entity, Use Case- 어플리케이션의 핵심 기능, 비즈니스 규칙 등을 캡슐화
포트- 도메인 모델과 외부 통신 인터페이스 정의
- Use Case에서 포트를 구현하거나, 호출해 외부 요소와 통신할 수 있음
어댑터- 특정 포트에 연결되어 외부와 도메인간 통신을 가능하게함
- 외부 요소를 직접 다룸
- 라이브러리, 프레임워크에 종속적인 코드는 어댑터에 들어감
- 포트를 구현하기도 하고, 포트를 통해 Use Case를 직접 호출하기도함
헥사고날 아키텍처를 다른 방식으로 보는 방법- 입력 포트 & 입력 어댑터
Use Case를 호출- 출력 포트 & 출력 어댑터
Use Case로부터 호출되어 외부에 결과를 전달
프레젠테이션 (View, Controller)
도메인 (Use Case, Entity)
영속성 (Repository Impl, Data Source)
View
Controller (Adapter)- 외부 라이브러리와 프레임워크를 연결하는 부분을 담당하는 Adapter
Port
Use Case
Entity
Use Case
Port
Repository Impl (Adapter)- 외부 라이브러리와 프레임워크를 연결하는 부분을 담당하는 Adapter
Data Source
Controller 에서는 Port에만 접근 가능하며 이를 통해 Use Case를 호출
Use Case에서는 Repository 쪽에 구현된 Port를 통해 결과를 보장
위 과정을 통해 도메인을 POJO로 유지,
외부라이브러리, 프레임워크의 변화로부터 도메인을 보호할 수 있음
헥사고날 아키텍처 적용하기
- 서비스와 레포지토리의 메소드를 인터페이스로 추출
- 도메인 분리
Jpa Member를 서비스에서 직접 사용하지 않고
Domain의 Member를 따로 구현하여
서비스에서 이를 의존하도록 바꿔 패키지간 양방향 의존성을 끊을 수 있음
- 패키지 네이밍 변경
클린 아키텍처를 적용하면 항상 좋은가?
패키지 구조
레이어드 아키텍처
헥사고날 아키텍처
두가지를 비교했을 때 헥사고날 아키텍처의 패키지량, 코드량, 복잡도가
레이어드 아키텍처보다 상승함 !
의존관계가 크게 복잡하지 않다면 레이어드 아키텍처가 유리할 것 !
그럼 언제 헥사고날 아키텍처를 사용하면 좋은가 ???
1. 대규모 프로젝트
2. 프로젝트 일원 모두가 클린 아키텍처를 이해하고 있는 경우
3. 외부 요소의 변화가 잦은경우
