DDD - Module (package)

- 출처: 도메인 주도 설계 - 에릭 에반스

- Module (package)

인간이 한번에 받아들일 수 있는 인지력은 한계가 있기 마련이다. 만약 legacy 시스템을 운영해야 하는 업무를 수행한다고 가정해보자. legacy가 방대하다면 해당 시스템을 한번에 이해하기란 쉽지 않을것이다. 그럼 어떻게 해당 시스템을 분석할것인가? 가장 기본적인 접근법은 특정 단위로 나누어서 분석하고 그들간의 관계를 파악하는것이다.

 

module은 왜 필요한가? 위에서 언급한대로 인간의 인지적인 과부하를 줄이기 위한 단위가 필요한데 이것이 바로 module 또는 package 라고할 수 있다. module을 분석하는 관점에는 2가지가 있다. 하나는 module과 module간의 관계를 파악하는 관점이고, 다른 하나는 해당 module에 대한 세부사항을 파악하는 관점이다.

 

SW 코드를 공부해본적이 있다면 "높은 응집력, 낮은 결합도(high cohesion loose coupling)" 라는 말을 많이 들어봤을것이다. 여기서 "높은 응집력"이란 단편적인 개념인 module은 일관성이 있어야 한다는 뜻이고, "낮은 결합도"란 사람이 인지력은 한계가 있으므로 module 간의 관계가 적어야 한다는것을 의미한다. 

 

이름을 부여할때는 도메인의 service와 마찬가지로 module 역시 유비쿼터스 언어를 차용하는것이 좋다.

 

module은 모델과 함께 발전한다. module을 리팩토링 한다는것은 모델과 코드를 리팩토링 한다는것과 같다. 

---

- 인프라스트럭쳐 주도 package

package 구조를 결정할 때 기술관련 framework가 영향을 주는 경우가 상당히 많다. 예를 들어 인프라스트럭처 코드와 UI 코드를 별도 package로 분리하려고 layered 아키텍처를 이용할 수 있다.

 

J2EE에서 업무로직은 세션 빈에, Data 접근은 Entity 빈에서 처리하는데 이렇게 되면 응집력이 떨어진다. 응집력이 떨어지면 어떤 하나의 개념을 이해하기 위해서는 머리속에서 서로 다른 package를 조립하여 하나의 Entity로 통합하는 수고가 필요하다.

 

또한 데이터 영속화, 비즈니스 계층, App 특화 계층, I/F 계층을 분리하는 tiered 아키텍처를 이용하는 경우도 있다. 하지만 이런 아키텍처를 선택하는 경우 어떤 module을 추가할 때, 개념적인 하나의 module을 추가했지만 물리적으로는 각 계층에 대해 4배 만큼의 module을 추가하는 느낌이 들 수 있다.

 

이렇듯 기술적으로 정교한 수준을 너무 세밀하게 package 구조를 잡으면 2가지 측면으로 비용이 발생한다.

 

• framework의 분할관계 때문에 코드에서 모델이 드러나지 않는다.
• 도메인 개발자들이 모델을 의미있는 조각으로 나누기가 힘들다.