2부. 소프트웨어에서 표현되는 모델 : 모듈 (Module)

이전글 : 2021.03.28 - [Domain Driven Design] - 2부. 소프트웨어에서 표현되는 모델 : 서비스(Service)

2부. 소프트웨어에서 표현되는 모델 : 서비스(Service)

 

모듈(Module)은 엔티티, 값 객체(vo), 서비스 등의 패턴들보다 더 익히 들어봤을 것이다.

 

그만큼 널리 오랫동안 사용되는 패턴으로서, 소프트웨어 설계를 공부하며 모듈이나 컴포넌트 같은 개념을 배운 경험도 있을 것이다. 모듈에 대해 알아보도록 하자

 

모듈 Module (혹은 패키지 Package)

" 개념적인 부분으로(코드로써가 아닌) 클래스들을 모아 높은 응집도, 낮은 결합도를 갖는 집합체 "  

 

어떻게 모듈을 사용했는지 경험을 떠올려보자

우리가 만들, 만들어가는, 만들었던 소프트웨어를 어떻게 바라봤을까?

 

아마 코드를 보기 전, 전체적인 구성에 대해 모듈화하여 이들의 관계 혹은 구성이 어떻게 되는지 그리며 시스템의 동작을 생각하곤 했던 경험이 다들 있을 것이다.

 

이처럼 우리가 모듈화를 하는 가장 큰 이유 중 하나는 우리의 인지적 과부화 때문이다.

 

작성할 클래스부터 최종적 목표인 소프트웨어까지, 세심한 부분에서 큰 시스템을 바라봤을 때 기술적인 문제부터 개발해야할 기능까지 막막하게 느끼고 압도당할 수 있다.

 

이때 모듈을 기준으로 하여, 모듈 내의 세부사항을 중점으로 보거나 혹은 모듈 간의 관계나 구성 등의 전체적인 부분을 보며 하나씩 개발해 나가는 것이다.

 

 

모듈이 무엇인지, 어떻게 모듈을 유용하게 사용했었는지 경험을 토대어  떠올려봤다. 그렇다면 어떻게 모듈을 잘 설계할 수 있는지 알아보자

 

모듈 설계 원칙

• 응집력 있는 개념들을 하나의 모듈에 담는다.
• 점점 심층적인 모델이 되도록, 모듈 간 결합도가 낮아지도록 도메인에 대한 이해, 개념을 변형하고 모듈에도 반영한다.
• 독립적으로 이해하고 논리적으로 추론할 수 있다는 의미에서 결합도를 낮추도록 한다.
• 높은 수준의 도메인 개념에 따라 모델이 분리되고, 그것에 대응되는 코드도 분리될 때까지 모델을 정제한다.
• Ubiquitous Language를 구성하는 것으로 모듈의 이름을 부여한다. (모듈은 도메인에 통찰력을 줄 수 있어야 함)

 

 

 

---

2부에서는 Entity, Value Object, Service, Modulee 4개의 패턴에 대해 알아보았다. 모델 주도 설계라고 해서 반드시 모든 것을 객체화하거나 객체라는 틀에 맞춰야 한다는 것은 아니다. 룰 엔진과 같은 도구의 지원을 받는 다른 모델 패러다임도 있는데, 이러한 패러다임 사이에서 실용적으로 타협점을 따져봐야 한다. 결국 이러한 기타 도구와 기법은 모델 주도 설계로 가는 수단에 불과하다.

 

예를 들어, 연산 및 계산 등의 수학적인 도메인에서 연산/계산은 객체 지향 패러다임에 맞추기 쉽지 않을 것이다. 차라리 룰 엔진에서 연산과 계산을 정의하는 것이 더욱 알맞아 보인다. 이 때 연산과 계산을 객체화하지 않고 비객체 구성요소로 두고 룰 엔진으로 처리하며 객체 시스템에 처리하도록 통합하면 된다.

 

이렇게 패더라임을 혼합하여 어떤 개념을 잘 표현할 수 있는 형식으로  모델링 할 수 있게 된다. 그리고 패러다임을 통합하기 위한 4가지의 법칙은 다음과 같다.

 

객체가 아닌 요소를 객체 지향 시스템에 통합하는 4가지 법칙

• 구현 패러다임을 도메인에 억지로 맞추지 않는다.
• Ubiquitous Language에 의지한다.
  유비쿼터스 언어는 이전 1부에서부터 강조했었다. 각종 패러다임, 도구에서 서로 일관된 언어를 사용한다면 설계의 각 부분이 복잡해지거나 이질적으로 변하는 것을 막을 수 있다.
• UML에 심취하지 않는다.
  가끔 UML 다이어그램과 같은 도구에 집착하여 그리기 쉬운 방향으로 모델을 왜곡할 수 있다. 다른 패러다임에서 사용되는 방식의 다이어그램이나 간단한 문장으로 설명하는 편이 더 나을 수 있다.
• 회의적이어야 한다.
  객체 지향 시스템에 다른 패러다임을 모델링을 지원하는 도구로써 사용하게 된다면 "과연 제 몫을 하고 있는가"에 의문을 가져야 한다. 어떤 규칙이 있다고 해서 값 비싼 룰 엔진이 꼭 필요한 것은 아니기 때문이다.