Week 3. 도메인 주도 설계

 

도메인 주도 설계는 말 그대로,

기술적인 인프라나 DB 스키마를 먼저 고민하는 것이 아닌

비즈니스 규칙과 프로세스가 우선인 도메인 중심으로 설계를 진행한다는 것이다.

 

어떤 도메인들이 필요한지, 각 도메인 비즈니스 규칙과 도메인 간의 결합 등이 

어떻게 유기적으로 맞물릴 수 있는가를 고민하고, 전체 구조와 흐름을 정하는 것이

이번 주차의 핵심이었다.

 

가장 큰 틀이 되는 아키텍처부터 생각했다.

 

--

 

여러 아키텍처들이 있지만 그중 레이어드/헥사고날/클린, 이 세 가지를 비교 분석했다.

 

레이어드야 주로 사용하던 것이니 나름 익숙했으나 나머지 둘은 개념조차 모를 정도로 생소했다.

하지만 레이어드 또한 알면 알 수록 내가 깊이 있게 이해하고 있지 않았구나 싶었다.

 

셋 모두 비즈니스 로직이 인프라를 몰라야 한다는 동일한 문제를 풀지만 의존 적용에 대한 방식이 다르다.

레이어드는 교체 가능성이 있는 곳에만 단방향으로 선택적인 적용을, 

헥사고날은 코어의 모든 출입구인 포트에,

클린은 의존성이 안쪽으로 향해야 하기에 모든 레이어 경계에 적용을 한다고 한다.

 

선택에 앞서 나만의 세 가지 기준을 세웠다.

1. 테스트가 원활히 가능한가.

2. 가독성이 괜찮은가.

3. 변경이 자유로운가.

 

헥사고날은 포트 구성이기에 복잡한 비즈니스 로직에 대응하거나 많은 분리가 이루어질 때 용이하다.

클린은 헥사고날과 마찬가지로 인프라 변경에 이점이 있으나 의존성의 절대 규칙으로 제한적이다.

 

기준을 기반으로 한 여러 이유를 따져봤을 때, 가장 적합해 보이는 것은 레이어드였다.

물론 과제에서도 레이어드 기반 설계를 추천하기도 했다.

 

도메인을 중점으로 하는 설계이기에 3 티어가 아닌 4 티어 레이어드 아키텍처를 선택했다.

 

--

 

패키지 구조에 대한 전략을 고민하기 전에 퍼사드에 각 계층별 책임에 대해 생각하고 들어가야 했다.

 

다른 건 몰라도 특히 애플리케이션 레이어의 퍼사드와 도메인 레이어의 도메인 서비스의 이해가 필요했다.

 

도메인 서비스는 도메인 레이어 안에 존재하기에 각 도메인에 넣기 애매한 로직을 추가하기 위해 만든 것이고,

퍼사드는 도메인 간의 유연한 결합을 위해 존재한다라고 이해했다.

 

그렇기에 도메인 서비스는 순수 비즈니스 로직만을 위해 존재하게 뜸하고,

퍼사드 또한 테스트 용이함을 위해 레포지토리 의존 없이 도메인을 위한 설계로 방향을 잡았다.

 

--

 

패키지 구조를 구성하는 데는 레이어 중심과 도메인 중심 설계가 있다.

 

전자는 주로 보아왔던 방식으로, 각 계층 내부에 도메인/서비스가 존재한다.

후자는 그 반대로, 도메인별로 계층을 각자 가지고 있는 것이다.

 

익숙한 방법으로 갈 것인지 새로운 길로 가볼 것인지 오래 고민했던 것 같다.

 

어떤 것을 택하든 장단점이 있었기에, 마찬가지로 나만의 기준을 세워 결정했다.

 

우선 코드를 열어보았을 때 빠른 체킹이 가능하도록 가독성이 좋아야 한다.

가급적 비슷하거나 같은 역할들의 파일은 모아두고 싶다.

도전을 해보고 싶다.

 

위 세 가지 기준을 토대로 결국 도메인 중심으로 패키지를 구성하기로 했다.

 

아무래도 마지막 이유가 제일 크지 않았나 싶다.

 

--

최종 패키지 구조

 

--

 

설계를 진행하면서 가장 큰 기준점이 되었던 것은 아무래도 이게 아니었을까.

 

테스트를 편하게 하기 위해선 어떤 방법이 가장 좋은가

 

 

테스트가 편해야 여러 테스트 케이스 작성과 그에 따른 구현이 쉬워진다.

 

 

애매모호한 선택의 길에 놓였을 땐 기준을 세워 방향을 결정하는 것이 바람직하다.

 

이번 기회에 나만의 개발 철학을 만들어 나아갈까 한다.