DDD - 개념적 윤곽

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

- 개념적 윤곽(Conceptual contour)

코드를 개발하다보면 유연하게 조합할 수 있도록 작은 크기로 기능을 나누기도 하며, 복잡성을 캡슐화하기 위해 기능을 더 큰 단위로 통합 하기도 한다. 이런 방법들은 지나치게 단순해서 일반 원칙으로 적용하기에는 부적절하다. 하지마 이런 방법들은 문제를 해결하기 위한 동기를 부여한다.

 

모델 혹은 설계를 구성하는 요소가 모놀리식 구조이면 기능이 중복되어 클라이언트는 인터페이스로부터 유용한 정보를 일부만 파악가능하다. 반대로 클래스와 메소드를 잘게 나누면 작은 객체들의 협력 방식을 이해하고 있어야 하기 때문에 클라이언트 객체가 무의미하게 복잡해진다.

 

도메인에는 잠재적인 일관성이 존재한다. 특정 모델을 발견하면 나중에 다른 영역과도 일관성이 유지될 확률이 높다. 이를 반복적으로 리팩토링 하다보면 유연한 설계가 된다. 이렇게 새로 알게된 개념이나 요구사항을 코드에 적용하다보면 개념적 윤곽(Conceptual contour)이 나타난다.

 

아주 유명한 높은 응집도와 낮은 결합도(High cohesion, Loose coupling) 기본 원리는 모듈이나 대규모 구조에 이르기까지 모든 규모의 설계에서 중요하다. 이는 코드 뿐만 아니라 개념에도 적용된다.

 

개념적으로 의미 있는 기능의 단위를 찾으면 그 결과로 만들어진 설계는 이해하기 쉬워진다. 만약 두 객체의 합이 도메인에서 의미를 갖는다면 해당 수준에서 구현해야 한다. 더 개별적인 단위로 나누거나 해당 기능을 넘어서는 수준을 처리해서는 안된다.

 

연속적인 리팩토링을 수행하는데 변경 범위가 지역적으로 한정되어있다면 모델이 현재 도메인에 적합할 확률이 높다. 만약 광범위한 변경을 야기하는 요구사항이 등장한다면 지식의 개선이 필요하다는 신호이다.

---

- Example

아래와 같은 대출 관리 시스템이 있다고 가정해보자. 이자와 수수료를 계산하는 계산기가 각각 정의되어 있고, 상환에 대한 내역이 있다.

 

 

 

만약 도메인을 조금 알고 있다면 이를 발생주의 회계원리에 입각하여 재 설계할 수 있다. 발생주의 회계기준은 현금이 지급되는 시점을 기준으로 하는것이 아니라 거래가 발생한 기점을 기준으로 하는것을 말한다.

 

 

 

기존 설계의 현금주의 회계 기준보다 발생주의 회계 기준 설계의 객체수가 1개 더 많지만 책임 분할은 크게 다르다. 새롭게 명시적으로 드러난 개념과 더불어 발생 기록표(Accrual schedule) 계층 구조의 응집력 때문에 해당 모델이 개념적 윤곽을 더 드러낸다고할 수 있다. (물론 이는 응용프로그램이 발전함에 따라 변경될 수 있다.)

 

만약 새로운 유형의 Accrual schedule(ex - Annual fee)가 추가되어도 Accrual schedule의 accrualsForDateRange() 메소드만 재정의하면 된다. 이정도의 요구사항 변경은 예상하고 위의 발생주의 회계 기준을 설계할 수 있었을것이다. 

 

만약 조기 상환 및 연체 상환에 대해 세분화된 규칙과 관련된 요구사항이 등장하면 어떻게 될까? 이자 상환과 수수료 상환에 가상적으로 동일한 규칙이 적용된다. 새로운 모델 요소는 본질적으로 하나의 Peyment(상환) 클래스에 연결된다. 만약 이전설계라면 두 Payment history 클래스간에 중복이 발생했을것이다.