1. 문제 상황
현재 프로젝트에서는 각 서비스에서 공통으로 사용하는 기능을 Common 모듈에 추가하여 관리하고 있었습니다. 처음에는 특정 서비스에서 필요한 기능이 다른 서비스에서도 요구될 때마다 Common 모듈에 포함시키는 방식으로 운영되었습니다.
그러나 시간이 지남에 따라 Common 모듈이 지나치게 많은 기능을 포함하게 되었고, 그 결과 아래의 사진과 같이 코드의 복잡도가 증가하고 수정 시 여러 서비스에 영향을 미치는 문제가 발생했습니다.
이러한 문제를 해결하기 위해 모듈 간의 명확한 기준을 세우고 아키텍처를 재구성하였습니다.
2. 과정
현재 프로젝트는 DDD(Domain-Driven Design) 기반으로 설계되었으며, 이를 바탕으로 아래와 같은 기준으로 영역을 분리했습니다.
1️⃣ "변경 기준"에 따른 분리
먼저, 모듈이 어떤 기준에 따라 변경되는지를 고려하여 영역을 나누었습니다. 주문 생성, 주문 완료, 주문 취소와 같은 도메인 로직은 비즈니스 요구사항에 의해 변경되는 반면, MySQL, Redis와 같은 인프라 관련 요소는 시스템 설계에 따라 변경되는 특징이 있습니다.
이에 따라 비즈니스 영역과 인프라 영역을 분리하여, 각각 독립적으로 변경될 수 있도록 개선하였습니다. 예를 들어, 특정 서비스에서 MySQL을 Redis로 변경하더라도, 도메인 로직에는 영향을 주지 않도록 인프라 계층을 따로 모듈화하여 설계하였습니다.
2️⃣ 책임 기준
비즈니스 영역 내에서는 담당하는 역할과 책임을 기준으로 구분하여 설계하였습니다. 크게 도메인 영역과 어플리케이션 영역으로 나눴는데, 도메인 영역은 도메인에 대한 핵심 비즈니스 로직을 담당하는 영역으로, 도메인에 대한 규칙이나 상태 변경 등 DDD Layer에서 도메인 영역에 해당되는 부분을 모듈화를 진행해 이 영역으로 구분했습니다. 또한 이 영역은 되도록 최소한의 의존성을 가지도록 했습니다.
어플리케이션 영역은 도메인 영역에 있는 모듈과 인프라 영역에 있는 모듈들을 활용하여, 트랜잭션 관리와 같은 서비스의 흐름을 조정하고 외부 시스템과 상호작용을 담당하는 모듈들이 있습니다.
즉, 도메인 영역은 비즈니스 로직과 상태 변경을 관리하는 역할을 한다면, 애플리케이션 영역은 이를 조합하여 서비스 전체의 흐름을 조정하고 외부 시스템과 연결하는 역할을 합니다.
3. 결과
최종적으로 현재 프로젝트 기준으로 하나의 서비스 즉, DDD 설계를 기준으로 하나의 바운디드 컨텍스트 안에 아래와 같은 app 영역과 domain 영역 infra 영역으로 분리했고,
하나의 어플리케이션 모듈은 아래와 같이 각 영역에 관해 의존성을 가지도록 설정하여 확장성에 유리하도록 개선했습니다.
