9장. 모듈(패키지) / IDDD (도메인 주도 설계 구현)

개요

---

# 참고

IMPLEMENTING DOMAIN DRIVEN DESIGN (도메인 주도 설계 구현) - 반 버논 지음

 

# 개요

DDD에 대한 기술서적을 읽고 DDD가 무엇인지 이해하고 어떻게 코드에 적용시킬 수 있는지 고민해 보려고 한다.

 

# 9장의 로드맵

• 전통적인 모듈과 배포 모듈성이라는 새로운 접근법의 차이점
• 유비쿼터스 언어에 따라 모듈 이름을 짓는 일의 중요성
• 기계적인 모듈 설계가 실제로 모델링의 창의성을 억누르는 상황
• 도메인 모델 밖에서 모듈이 수행하는 역할과, 새로운 바운디드 컨텍스트 보다 새로운 모듈을 선호해야 할 때가 언제인지

---

9장. 모듈

자바를 사요하고 있따면 이미 모듈과 친숙한 상태이다. 자바에선 이를 패키지라고 부른다. 

 

9-1. 모듈로 설계하기

DDD컨텍스트에서 모델 안의 모듈은 서로 간에 높은 응집도를 갖고 있는 도메인 객체를 담는 이름이 붙여진 컨테이너 역할을 수행하며, 각기 다른 모듈에 있는 클래스 사이에 낮은 결합도를 유지하는 것이 목표가 돼야 한다. DDD에서 사용되는 모듈은 단조롭거나 포과적인 저장소가 아니기 때문에, 모듈을 적절하게 이름 짓는 일도 중요하다. 

 

# 모둘 설계의 간단한 규칙

1. 모델링 개념에 맞춰 모듈을 설계하자

일반적으로 여러분은 하난 그 이상의 애그리게잇당 하나의 모듈을 갖게 된다.

 

2. 유비쿼터스 언어 에 맞춰 모듈을 명명하자

DDD는 기본적인 목적이기도 하지만, 여러분이 모델링을 하고 있는 개념에 관해 생각하면서 자연스럽게 다다르는 결과이기도 하다. 

 

3. 모델에서 사용하는 일반적인 컴포넌트 타입이나 패넡에 따라서 기계적으로 모델을 생성하지 말자

모든 애그리게잇을 하나의 모듈로, 모든 서비스를 다른 하나의 모듈로, 모든 팩토리를 또 다른 하나의 모듈로 분리한다면 모듈화의 장점을 전혀 취할 수 없다. 이런 접근은 DDD 모듈의 지향점을 노치고 있으며, 창의적으로 풍부한 모델을 만드어가는 과정을 제약한다. 

 

4. 느슨하게 결합된 모듈을 설계하자

모듈 사이에 독립성을 최대한 보장한다면 느슨하게 결합되 클래스와 같은 이점을 취할 수 있따. 

 

9-2. 기본 모듈 명명 규칙

최대한 의미를 담고 사려 깊게 이름을 정해서 모듈을 생성하도록 노력하자. 기존 모듈의 이름까지도 대담하게 바꿀 수 있을 정도로 공격적으로 접근해야 함을 의미한다. 우리는 특정 목적에 따라 사용할 물건을 찾는데 아무 문제가 없을 것이고, 의도에 맞춰 사용하길 주저하지 않을 것이다. 모든 것이 잘 정리되어 깔끔하다. 이렇게 모듈에 따른 조직화가 잘 갖춰진 상태에선 식기류가 담긴 서랍에서 컵과 컵받침을 찾을 수 있길 기대하는 사람은 없다.

 

9-3. 모델을 위한 모듈 명명 규칙 

모듈 이름에서 다음으로 이어지는 부분은 바운디드 컨텍스트를 나타낸다. 바운디드 컨텍스트에 기반해 이름을 짓겠다는 결정은 바람직한 접근이다.

 

상업적 제품 이름을 모듈 이름에 사용하지 않았다 브랜드 이름은 바뀔 수 있으며, 때로 제춤 이름과 근간을 이루는 바운디드 컨텍스트 사이에 직접적인 연관이 없을 때가 있다. 컨텍스트를 이름으로 식별하는 편이 훨씬 중요한데, 이야말로 팀의 논의에서 사용되는 언어이기 때문이다. 따라서 목표는 유비쿼터스 언어를 반영하는 것이다. 

com.albamon.agilepm.domain.service

 

여기에 도메인 서비스를 둬야 한다는 요구사항은 없다. 이를 모델에서 중간 단위 서비스를 담는 작은 계층이라 생각하거나 이런 계층을 둘러싸고 있다고 생각한다면, 여기에 도메인 서비스를 둘 수 있다. 그러나 이런 접근법은 얼마 지나지 않아 서비스에서 논의했던 애너믹 도메인 모델로 이어질 수 있따는 점에 주의하자. 

 

모델과 서비스를 두 패키지로 나누지 않을 땐, model 모듈을 버리고 모든 모델 모듈을 domain아래에 둘 수도 있다.

com.albamon.agilepm.domain.coceptname

이는 확실히 불필요해 보이는 한 단계를 제거해준다. 하지만 추후에 domain.service 하위 모듈에 몇 가지 도메인 서비스를 두기로 결정한다면 어떻게 될까? 그런 시점이 오면 domain.service를 생성하지 않은것을 후회 할 수도 있다.

 

하지만 이름에 영향을 주는 요소 중 이보다 더 중요하게 고려해야 하는 부분이 있다. 우리가 도메인을 개발하지 않았다는 점을 잊지 말자. 도메인이란 우리가 일하고 있는 비즈니스에 해당하는 노하우를 담고 있는 영역 일부다. 우리가 설계하고 구현하는 대상은 도메인의 모델이다. 따라서 최종적으로 모델의 모듈에 대해 이름을 지을 땐, domain.model이 가장 적절해 보인다.

 

9-4. 다른 계층 속의 모듈

어떤 아킽텍처를 선택하든, 하상 모델에 행당하지 않는 컴포넌트의 모듈을 생성하고 이름을 붙여야 한다. 여기선 기존의 계층 아키텍처에서 사용할 수 있는 옵션은 무엇인지 노의하는데, 이느 계층 아키텍처뿐 아니라 그 밖의 다른 아키텍처 스타일에도 적용할 수 있다. 

 

도메인 모델을 다루는 애플리케이션에 사용되는 전형적인 계층적 아키텍처에선 '사용자 인터페이스. 애플리케이션, 도메인, 인프라'와 같이 계층을 쌓게 된다. 애플리케이션의 피요에 맞춘 각 계층별 컴포넌트의 유형에 따라 각 계층에 속하는 모듈도 달라지게 된다. 

 

사용자 인터페이스 계층과 레스트풀 시소스의 지원에 따른 영향을 생각해보자. 여러분의 리소스는 XML, JSON, HTML등의 표현 상태를 만들어서 GUI 클라이언트에게 서비스를 제공할 수 있다. 그러나 레스트풀 리소스는 표현을 만들 때 레프레젠테이션 레이아웃을 포함시켜선 안 된다. 따라서 REST를 지원하는 사용자 인터페이스 계층에선 적어도 다음과 유사한 이름의 두 가지 모듈을 마련하게 된다.

com.albamon.agilepm.resource
com.albamon.agilepm.resource.view

레스트풀 리소스는 resources 패키지 안에서 유지 관리돼야 한다. 반면 표현에 관한 순수한 관심사는 하위 패키지인 view 내의 컴포넌트로서 제공돼야 한다.

 

9-5. 바운디드 컨텍스트보다 모듈

우리는 응집도 있는 도메인 모델 객체를 여러 모델로 나눌지, 하나로 유지할지 결정해야 할 때 신중해져야 한다. 때론 실제 도메인의 언어가 확실하게 보일 수도 있지만, 어떨 땐 용어가 애매할 수도 있다. 용어가 애매하고 컨텍스트적 경계를 만들지 여부가 분명치 않을 땐, 우선 이를 나누지 않고 하나로 유지하는 편을 고려 하자. 이 접근법은 분리를 위해 두꺼운 바운디드 컨텍스트를 사용하는 대신, 좀 더 얇은 모듈의 경계를 활용한다.모듈을 대신해 바운디드 컨텍스트를 사용할 수 없다는 점을 알아야 한다. 응집도 높은 도메인 객체를 모듈화하고 응집력이 없거나 낮은 객첼를 분리하기 위해 모듈을 사용하자.

 

즉, 언어적 측면에서 좀 더 큰 단위로 구분할 필요가 없을 때 새로운 바운디드 컨텍스트를 만들기보다는 모듈의 사용을 고려해야 하는 이유를 이해해야 하자.