CH06 객체 지도

도메인 모델이 결국 근본이며 설계는 도메인 모델을 지도로 삼아야한다

이번 챕터의 핵심은 '설계시 단건 단건들의 기능(유스케이스)들을 근거로 삼지 말고 근본이라 할 수 있는 도메인 모델을 근거로 삼아야한다' 는 것이다.

어찌보면 당연스럽게 행하던 것들인데 의식적으로 거기에 의미를 붙이고, 당연시 여겼던 것에 왜? 라는 질문과 답을 해보는 챕터라 할 수 있다.

처음에는 왜 자꾸 당연한 이야기를 이렇게 복잡하게 하지 싶었는데, 반대로 내가 이것에 대해서 질문을 받았을 때 명확하게 책에서 말하는 것처럼 체계적으로 대답하지 못할 것 같다는 생각이 들어서 수긍하게 되었다.

기능을 중심으로 구조를 종속시키는 접근법은 범용적이지 않고 재사용이 불가능하며 변경에 취약한 모델을 낳게 된다. 이와 달리 안정적인 구조를 중심으로 기능을 종속시키는 접근법은 범용적이고 재사용 가능하며 변경에 유연하게 대처할 수 있는 모델을 만든다.

기능 설계 vs 구조 설계

훌륭한 설계란

미래를 대비하는 가장 좋은 방법은 변경을 예측하는 것이 아니라 변경을 수용할 수 있는 선택의 여지를 설계에 마련해 놓는 것이다.

좋은 설계는 나중에라도 변경할 수 있는 여지를 남겨 놓는 설계다. 설계를 하는 목적은 나중에 설계하는 것을 허용하는 것이며, 설계의 일차적인 목표는 변경에 소요되는 비용을 낮추는 것이다.

변경은 실제로 자주 일어나며, 변경이 일어나지 않는다고 해도 설계를 할 때 변경을 계속 대비하고 어떻게든 변경 비용을 낮추는 방향으로 설계를 하는 것이 좋은 설계라는 생각이 든다.

기능을 중심으로 한 설계가 안좋은 이유

기능 분해는 자주 변경되는 기능을 중심으로 설계한 후 구조가 기능에 따르게 한다. 그런데 기능은 자주 변하기 마련이며 큰 기능이 작은 기능들로 분해되고 각 기능이 서로 밀접하게 결합된 구조는 변화에 취약할 수 밖에 없다. 변화에 취약하다는 말은 작은 변경도 서로 강결합된 구조로 인해서 높은 변경 비용을 유발할 여지가 있다는 것이다.

그래서 자주 바뀔 수 있는, 변경의 여지가 큰 기능 보다 변경의 여지가 적은 안정적인 객체 구조를 근간으로 한 설계를 우선하고 기능이 구조를 따르게 하는 것이 좋다.

안정적인 재료: 구조

결국 설계는 도메인 모델을 기반으로 이뤄져야 한다. 왜? 도메인 모델이 '본질적'인 설계의 재료이기 때문이다. 여기서 말하는 '본질적'의 의미에 대한 책 문구를 보자.

본질적이라는 것은 변경이 적고 비교적 그 특성이 오랜 시간 유지된다는 것을 의미한다.

도메인 모델이 가지고있는 개념과 규칙들은 비교적 변경될 확률이 적기 때문에 이를 재료로 구조를 만들고 기능이 이를 따르게 하는 것이 변경 비용을 최소화 하는 설계라 할 수 있다.

멘탈 모델 관점으로 바라본 올바른 설계

최종적인 결과물인 시스템 이미지와 사용자 모델 간의 차이가 적을 수록 좋은 설계라고 할 수 있다.

유스케이스 정의와 설계시용도

유스케이스 정의

계속해서 유스케이스와 도메인 모델을 비교하며 도메인 모델이라는 안정적인 재료를 통해 구조를 먼저 설계하고 그 후에 기능을 고려하라고 강조하고 있다.

그런 의미에서 책에서 유스케이스에 대해서 어떻게 표현하고 평가하고 있는지를 짚어보면 좋을 것 같아서 따로 정리한다.

유스케이스는 시스템이 외부에 제공해야 하는 행위만 포함하기 때문에 유스케이스로부터 시스템의 내부 구조를 유추할 수 있는 방법은 존재하지 않는다. 유스케이스는 객체의 구조나 책임에 대한 어떤 정보도 제공하지 않는다.

물론 유스케이스 텍스트 안에서 도메인 모델에서 사용할 용어에 대한 힌트를 얻을 수도 있다. 그러나 유스케이스 안에 도메인 모델을 구축할 수 있는 모든 정보가 포함돼 있다는 착각에 빠지지 말기를 바란다. 유스케이스 안에는 영감을 불러일으킬 수 있는 약간의 힌트만이 들어 있을 뿐이다.

전반적으로 아무튼 평가가 박하다. 하지만 아래와 같이 좋게 인식하는 측면도 있다.

유스케이스의 가치는 사용자들의 목표를 중심으로 시스템의 기능적인 요구사항들을 이야기 형식으로 묶을 수 있다는 점이다. 이것은 요구사항을 기억하고 관리하는 데 필요한 다양한 정신적 과부하를 줄인다. 유스케이스의 목적은 연관된 시스템의 기능을 이야기 형식으로 모으는 것이다.

유스케이스 용도

그렇다면 설계를 할 때 유스케이스는 어떠한 용도로 사용될 수 있을까?

유스케이스는 사용자에게 제공할 기능을 시스템의 책임으로 보게 함으로써 객체 간의 안정적인 구조에 책임을 분배할 수 있는 출발점을 제공한다.

책에선 이렇게 표현하고 있다.

유스케이스와 도메인 모델의 관계

사실 유스케이스와 도메인 모델 사이에서 도메인 모델이 우선인듯 표현되고 있으나, 유스케이스가 결국 요구사항이 스토리 텔링 형식으로 표현된 것이기 때문에 유스케이스 역시 만약 주어진다면 도메인 모델을 체계화하기 위해서 참고해야할 정보이다.

책에서도 아래와 같은 인용구가 있는데,

요구사항들을 식별하고 도메인 모델을 생성한 후, 소프트웨어 클래스에 메서드들을 추가하고, 요구사항을 충족시키기 위해 객체들 간의 메시지 전송을 정의하라[Larman 2001]

여기서도 도메인 모델을 생성하기 위해서 요구사항을 식별해야한다는 이야기를 하고 있고 요구사항을 식별하기 위해서는 유스케이스가 만약 주어진다면 참고하는 것이 맞다고 본다.

하지만 책에서도 강조하고 있고 나도 공감하는 것이 유스케이스로 표현될 수 있는 '기능' 이 도메인 모델을 파악하고 체계화 하는 것에 주가 되어선 안된다는 것이다. 단지 유스케이스는 참고가 될 뿐인 것이다.

유스케이스는 단지 시스템에 요구되는 여러가지 기능들이 작게 단위로 쪼개져서 스토리 형식으로 표현된 것일 뿐이고 도메인 모델은 유스케이스, 요구사항, 사용자 모델(사용자가 시스템에 대해서 가진 멘탈 모델) 들을 종합적으로 판단하여 구축해야한다.

예제로 짚어보는 좋은 설계

이번 챕터에서 계속해서 강조되는 것은 '변경 가능성이 적은', '본질적이고 근본적인' 도메인 모델을 설계의 근간으로 삼아야 한다는 것이다. 책에서 들고 있는 예시를 통해서 이걸 살펴보자.

위와 같이 중도 해지 이자액을 계산하라는 시스템이 요구 받는 내용이 있을때, 이를 단순히 기능에 대한 해결에 중점을 둘 것이 아니라 도메인 모델을 감안한 구조적 설계를 한다면 아래와 같은 다이어그램이 나올 수 있다.

위 설계는 도메인 모델을 기반으로 객체 구조를 설계한 것인데 이것이 안정적인 설계인 이유는 '도메인 모델'이 근본적으로 안정적이기 때문이다. 안정적이라는 말은 변경 여지가 적다는 것을 의미한다.

1. 도메인 모델을 구성하는 개념은 비즈니스가 없어지거나 완전히 개편되지 않는 한 안정적으로 유지된다. 정기예금 도메인에서 정기예금과 계좌, 이자율, 이자 라는 개념은 정기예금이란 금융상품이 없어지거나 완전히 개편되지 않는 한 안정적으로 유지되는 개념이다.

2. 도메인 모델을 구성하는 개념 간의 관계는 비즈니스 규칙을 기반으로 하기 때문에 비즈니스 정책이 크게 변경되지 않는 한 안정적으로 유지된다. 정기예금 도메인에서 이자는 정기예금이 만기가 ㅗ디거나 중도 해지를 하는 경우에 한해서 단 한 번 지급된다. 따라서 계좌와 이자 간의 0..1 관계는 이와 같은 핵심적인 비즈니스 규칙이 변경되지 않는 한 동일하게 유지될 것이다.

위 설명에도 자세히 나와 있듯 계속해서 강조되고 있는 것이 해당 도메인에서 근간에 자리하고 있는 개념, 상식, 변할 가능성이 거의 없는 뿌리 수준의 체계, 약속을 기반으로 도메인 모델을 체계화하고 이를 기반으로 객체 구조를 설립하는 것이 좋은 설계라는 것이다.

좋은 설계란 곧 기능의 변화에 유연하고, 변경에 대한 수정 비용이 적은 설계를 의미한다. 이것이 가능하려면 변경의 여지가 거의 없는 도메인 내용들을 충실히 반영하고 있는 객체 구조가 자리잡고 있어야만 한다.

만약 저기서 단리 뿐만이 아니라 복리에 대한 중도 해지 이자율까지 줘야한다는 기능 추가가 발생하면 아래와 같이 확장만 하면 된다. 좋은 설계인 덕분에 쉽게 변경 및 확장이 가능한 것이다.

연결완전성과 가역성

연결완전성이란 도메인 모델링에서 사용한 개념을 프로그램이 설계에서의 객체와 클래스로 매끄럽게 변환할 수 있다는 것이다. 동일한 맥락에서 가역성은 반대로 코드에서 모델로 매끄러운 흐름을 의미한다.

책에서 설명하고 있듯 객체 지향 패러다임이 강력할 수 있는 이유는 이 두 가지 개념이 성립할 수 있는 패러다임이기 때문이다. 이것은 객체 지향 이전의 패러다임이 충족시키지 못했던 개념들이다.

연결완전성과 가역성이 성립하는 객체 지향 패러다임은 도메인 모델이라는 멘탈 모델을 그대로 프로그래밍의 세계에서 구현할 수 있는 패러다임이며, 현실의 도메인 모델을 충실하게 반영하고 있는 만큼 협업에 용이하고 안정적인 설계가 가능할 수 있다.