레이어드 아키텍처 (그런데, clean architecture를 곁들인)

[1] 아키텍쳐 비교

(1) 레이어드 아키텍처 (layered architecture)

출처 : https://cat-minzzi.tistory.com/74

1. 상위 계층 → 하위 계층 호출의 단방향 흐름을 유지한다.
   1. 상위 계층에 필요한 기능을 하위 계층의 구현으로 전달한다.
   2. 하위 계층의 변경이 상위 계층에 영향을 미친다. DB 계층이 변경되면 Service 계층이 변경될 수 있다.
2. DIP ❌ , OCP ❌
   1. DIP :  단방향으로 의존하고 있으므로 DIP 는 만족하지 않는다.
   2. OCP : 직접 의존으로 하위 계층에 변경에 따라 상위 계층이 함께 변경될 수 있기 때문에 OCP 를 위반한다.

 

(2) 헥사고날 아키텍처

출처 : https://tech.kakaobank.com/posts/2311-hexagonal-architecture-in-messaging-hub/

1. 모든 의존 방향이 도메인으로 단방향성으로 흐르고 있는 구조이다.
   • 장점 : 비즈니스가 중심적으로 보호되고 변경에 견고하다.
2. Adapter & Port 패턴 : 통해 데이터 계층과 API 계층이 비즈니스 로직을 의존한다.
   • 장점 : 다양한 외부 인터페이스(API, MessageQueue, WebSocket 등) 에 동일한 비즈니스 로직을 전달 가능하다.
   • 단점 : 소통 창구(Port) 가 생성될 때마다 관련된 모든 인터페이스 변경이 필요해 오버 엔지니어링이 될 수 있다.
3. DIP ⭕️ , OCP ⭕️
   1. DIP : 코어가 외부 구현에 의존하지 않고, 추상화된 포트를 통해 상호작용이 가능하다.
   2. OCP : 어댑터를 추가하거나 수정하여 코어의 변경 없이도 시스템 확장이 가능하다.

 

(3) 클린 아키텍처

출처 : https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html

 

1. Robert C Martin 이야기 : 의존성 규칙은 외부에서 내부로, 저수준 정책의 변경에 고수준 정책에 영향을 미치지 않도록 한다. 고수준 정책은 비즈니스 로직, 저수준 정책은 세부 사항들을 말한다.
   1. Hexagonal Architecture 는 Clean Architecture 의 구현 방법 중 하나이다. (Hexagonal Architecture != Clean Architecture)
2. Usercase & Port 패턴 : 비즈니스 로직으로 데이터 계층과 API 계층이 의존하도록 한다. 응용 계층이 외부 계층과 소통하면서 외부에서 사용할 수 있도록 가공한다. 
3. DIP ⭕️ , OCP ⭕️
   1. DIP : 고수준 모듈(Use Case, Domain)이 저수준 모듈(Interface Adapter, Infrastructure)에서 독립적으로 동작할 수 있다.
   2. OCP : 추상화된 경계와 계층 간 분리를 통해 기존 코드를 수정하지 않고 새로운 기능을 확장

 

 

(4) 레이어드 + 클린 아키텍처

1. 컴포넌트 의존성 방향

컴포넌트 의존 방향

1. 가장 익숙한 레이어드 아키텍처에서 클린 아키텍처 개념을 주입시킨 방법이다.
   1. 모든 의존 방향을 비즈니스 로직 방향으로 향하도록 해서 변경에 유연하도록 한다.
   2. 비즈니스 레이어는 행위(interface)만 명시하고, 세부 구현에 대해서는 몰라야 한다.
2. 컴포넌트 구성
   • Facade : 각 Manager 의 컴포넌트들을 조합해 하나의 기능을 구현하기 위한 컴포넌트
   • Manager : DB 쿼리를 비즈니스 요구사항에 맞도록 캡슐화하기 위한 컴포넌트
   • Repository : DB 에 관한 명세를 정의하는 인터페이스
   • RepositoryImpl : DB 에 관한 명세에 관한 세부 구현을 담당하는 클래스
3. DIP ⭕️ , OCP ⭕️
   1. DIP : 고수준 모듈에서 행위만 명시하고(e.g. LectureRepository), 저수준 모듈에서 세부 구현을 통해 (e.g. LectureRepositoryImpl) 독립적으로 동작할 수 있다.
   2. OCP : 추상화된 경계와 계층 간 분리를 통해 기존 코드를 수정하지 않고 새로운 기능을 확장할 수 있다.

 

2. 패키지 의존성 방향

• 패키지 방향성 또한 고려사항이다. 이전 클린코드에서 언급했던 것과 같이 business 패키지로 의존성이 향하도록 한다.
• business 패키지는 common 과 domain package 에만 의존할 수 있다.

 

 

Reference

• [kakaobank tech] 유일한 멀티모듈 헥사고날 아키텍처 : 메시지 허브 적용기 : https://tech.kakaobank.com/posts/2311-hexagonal-architecture-in-messaging-hub/
• [우아한 기술블로그] 주니어 개발자의 클린 아키텍처 맛보기 : https://techblog.woowahan.com/2647/ㅇ
• 로버트 마틴 - 클린 아키텍처 : https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html