CQS를 곁들인 헥사고날(Hexagonal) 아키텍처 패키지 구조와 클래스 네이밍

✢ 프로젝트에서 헥사고날 아키텍처를 적용하기로 했고, MSA 방식으로 각자 분리된 담당 서비스를 개발한다. 아무리 분리된 서비스라고 해도 처음에는 패키지 구조나 네이밍 컨벤션을 정해놓는 게 추후에 서로 코드리뷰할 때 편하고 여러 장점이 있는 것 같아서 미리 설계하였다. 

1. 헥사고날 아키텍처 구조

에 대한 것은 이전 포스팅을 확인해주세요.

2023.07.06 - [👨‍👩‍👧‍👦 Project/📩 DevTalk] - 헥사고날(Hexagonal) 아키텍처를 공부해 보자 (with Layered, Clean Architecture)

2. 내가 생각한 패키지 구조

src.groupname
          ㄴ global
                  ㄴ config
                  ㄴ util
                  ㄴ error
                         ㄴ exception
                         ㄴ handler
           ㄴ {애그리거트 이름}
                   ㄴ adapter
                   |        ㄴ in
                   |        |   ㄴ web
                   |        |        ㄴ dto
                   |        |
                   |        ㄴ out
                   |             ㄴ persistence
                   |             ㄴ producer
                   |
                   |
                   |
                   |
                   ㄴ domain
                   |
                   |
                   |
                   ㄴ application
                                ㄴ port
                                |     ㄴ in
                                |     |   ㄴ dto
                                |     |      
                                |     |
                                |     ㄴ out
                                |          ㄴ repository
                                |          ㄴ producer
                                | 
                                |
                                ㄴ validator

 

3. 클래스 및 인터페이스 네이밍 규칙 (수정됨)

• global.error.exception: ~Exception
• global.util: ~Utils
• global.config: ~Config
• adapter.in.web: ~ApiController
• adapter.in.web.dto: ~Input, ~Output
• adatper.in.consumer: ~Consumer
• adapter.out.producer: ~Producer
• adatper.out.persistence:  ~QueryRepo
• application.port.out.repository: ~Repo, QueryableRepo
• application.port.in.dto: ~Req, ~Res
• application.port.out.producer: ~ProducerPort
• application.validator: ~Validator
• application.port.in: ~UseCase
• application: ~Service

 

4. 기타 규칙

1. 어댑터에서 접근해야 하는 포트들은 public
2. 도메인 클래스들은 서비스 그리고 잠재적으로 어댑터에도 접근 가능하도록 public
3. 서비스는 인커밍 포트 인터페이스 뒤에 숨겨질 수 있기 때문에 package-private(java: default)
4. 애플리케이션 계층이 인커밍/아웃고잉 어댑터에 의존하지 않기
5. adapter 패키지 내에서는 모두 package-private

 

5. CQS(Command Query Separation) 패턴

기존에는 Repository 수준에서 CQS를 적용하고자 했다. 하지만 내가 개발하고자 하는 서비스는 Command 쿼리의 비중이 적었기에 괜히 의존성만 늘어나는 문제가 있었다. 따라서 조회용 Repository는 분리하되 쓰기용은 따로 분리하지 않고 JpaRepository를 상속한 인터페이스를 사용하기로 했다. 

Command와 Query를 분리하는 디자인 패턴

CRUD(Create, Read, Update, Delete)에서 Command는 Create, Update, Delete에 해당하는 개체의 상태를 변경하는 작업이고, Query는 Read에 해당하는 개체를 단순 조회하는 작업이라고 볼 수 있다.

하나의 메서드는 Command와 Query 둘 중 하나의 역할만 해야 한다.

읽기와 쓰기를 분리함으로써, 유지보수나 가독성에 도움이 된다고 생각한다.

따라서 나는 해당 프로젝트에서 Repository와 UseCase에서 클래스 단위로 CQS 패턴을 적용하고자 한다. 

 

6. CQS와 CQRS 차이점

CQRS는 Command and Query Responsibility Segregation)으로 CQS의 확장된 수준이라고 생각하면 된다.
하지만 CQS는 명령과 조회를 연산 수준에서 분리하지만, CQRS는 개체나 시스템 수준에서 분리한다는 차이가 있다.