객체지향의 사실과 오해 - 구조

- 이 글은 조영호의 객체지향의 사실과 오해를 기반으로 작성되었습니다. (가능하면 꼭 읽어보는것을 추천드립니다.)

- 도메인 모델

은행에서는 고객의 자산을 관리하고 보호하기 위해, 게임에서는 재미를 위해 또 병원에서는 환자의 진료 및 업무 관리를 위해 소프트웨어를 사용한다. 이처럼 사용자가 프로그램을 사용하는 대상 분야를 도메인이라고 한다.

 

모델은 복잡한 세상속에서 필요한 것들을 추려낸것이다. 만약 필요한 것만 추려내고 문제와 관련없는 나머지 세부사항들을 무시하는 추상화를 한 모델이 없다면 너무나 복잡하고 고려할것이 많아서 프로젝트 기간이 아무리 길다 한들 개발자들은 소프트웨어를 만들어내지 못할것이다.

 

이렇게 도메인과 모델의 정의를 고려할 때 도메인 모델이란 사용자가 소프트웨어를 사용하는 대상 분야에서 문제와 연관된 사항들을 선택적으로 단순화한 것이다. 관련된 소프트웨어 이해관계자들이 도메인에 대해 생각하는 관점이라고 할 수 있다.

 

도메인 모델은 단순한 다이어그램이 아니라 멘탈 모델이다. 멘탈 모델이란 자신, 다른 사람, 환경, 자신이 상호작용하는 사물들에 대해 갖는 모형이다. 도널드 노먼은 멘탈 모델을 사용자 모델, 디자인 모델, 시스템 이미지의 3 가지 요소로 구분하였다.

• 사용자 모델: 사용자가 제품에 대해 갖고 있는 개념들의 모습
• 디자인 모델: 설계자가 마음 속에 갖고 있는 시스템에 대한 개념화
• 시스템 이미지: 최종 제품

사용자 모델과 디자인 모델이 동일하다면 이상적이겠지만 설계자는 사용자와 직접적인 상호작용을 할 수 없기 때문에 시스템을 통해서만 의사소통 한다. 설계자는 디자인 모델을 기반으로 만든 시스템 이미지가 사용자 모델을 정확하게 반영할 수 있도록 노력해야 한다.

---

- 표현적 차이

제일 처음 도입부에서 얘기한적이 있듯이 소프트웨어 객체는 현실 객체를 반영한것이 아니다. 현실 객체를 은유하여 재창조하는것이다. 이런 과정에서 현실 객체와 소프트웨어 객체의 의미적 거리가 발생하는데 이를 표현적 차이라고 한다.

 

현실 객체를 은유하라는 말이 너무 추상적으로 느껴질 수 있겠다. 이 말의 의미는 사용자가 도메인에 대해 생각하는 개념을 은유하라는 의미이다. 훌륭하거나 정교한 소프트웨어란 객체를 얼마나 현실적으로 잘 고증해냈느냐에 따라 판가름되지 않는다. 도메인 모델을 통해 표현되는 도메인 객체들을 잘 은유했느냐를 신경써야 한다.

위의 다이어그램은 사용자가 계좌와 이자에 대해 생각하는 일종의 도메인 모델이라고 볼 수 있다. 이 도메인 모델을 기반으로 소프트웨어를 구축하기 위해서는 아래의 다이어그램과 같은 방식으로 구현 부분을 작성할것이다.

---

- 안정적인 도메인 모델

앞의 글에서 도메인 모델링은 구조를 수집하는데 구조 설계는 안정적이라고 했었다. 사용자가 생각하는 도메인 모델링을 잘 은유해야 하는 이유는 도메인의 본질적인 측면을 가장 잘 이해하는 사람이 바로 사용자이기 때문이다.

 

소프트웨어의 기능은 시간이 지남에 따라 자주 변한다. 하지만 사용자가 이해하고 있는 본질적인 측면은 기능처럼 자주 변하지 않는다. 따라서 설계를 하거나 코드를 만들 때 이 도메인 모델을 따라 만들어야 변경에 쉽게 대처할 수 있다. 도메인 모델은 안정적인 구조를 제공한다.