주요글: 도커 시작하기

처음 회사라는 곳에 들어가서 업무를 하던 시절, 그 회사에서 UML로 클래스 다이어그램을 그리는 사람은 나뿐이었다. 개발자가 10여명 정도 되는 작은 회사였는데 회사를 다니는 2년 8개월 동안 데이터 모델인 ERD를 그리는 사람이 1-2명 있는 정도였다.


사실 내가 그린 클래스 다이어그램은 데이터 모델이나 다름 없었다. 지금처럼 엔티티, 밸류에 대한 고민도 할 수 없었던 시기라 사실상 ERD를 클래스 다이어그램으로 그린 것이나 다름없었다. 약간의 차이라면 데이터뿐만 아니라 로직이나 다른 역할의 클래스들도 표현하곤 했다는 것이었다.


대학시절에 객체 지향이나 도메인 모델에 대해 제대로 공부하지 못했던 관계로 직장 생활을 하면서 눈치밥으로 도메인 모델이 이런 건가하는 감을 잡아 왔다.


사회생활 초기에는 ERD나 다름 없는 클래스 다이어그램이 도메인 모델 같았다. 특정 방법론을 따르는 SI 프로젝트에 참여했을 때 설계는 모두 데이터 중심이었고, 지식이 부족했던 당시에 읽었던 책들도 비슷한 내용을 담고 있었다.


그런데, 설계에 대한 여러 책들을 읽다보니 도메인 모델은 그런 것이 아니었다. 명쾌하게 답을 내릴 수 없었지만, 도메인 모델이란 것은 단순히 ERD의 클래스다이어그램 버전은 아니라는 생각이 들었고, 조금 더 객체 설계에 가깝다는 느낌을 받게 되었다.


[도메인 모델이란?]


아직도 도메인 모델이 뭐다라고 꼭 찝어 한 줄로 정의할 수 없기에, 도메인 모델이 뭔지 알아보고자 이런 저런 문서를 뒤져보았다.


우선, '도메인 모델'이란 단어에 출현하는 '도메인'과 '모델'에 대한 이해가 먼저 필요할 것 같다. '도메인Domain'에 대한 정의부터 뒤져보기로 했다. 위키피디아님의 정의(http://goo.gl/gw4w84)에 따르면, '도메인 공학'은 다음과 같다.

A domain is a field of study that defines a set of common requirements, terminology, and functionality for any software program constructed to solve a problem in the area of computer programming, known as domain engineering.


컴퓨터 프로그래밍으로 문제를 해결하기 위해 만들 소프트웨어 프로그램을 위한 요구사항, 용어, 기능을 정의하는 학문 영역이 도메인 공학이다.

이 정의에 따르면, '도메인'은 해결하고자 하는 문제 영역 정도가 될 것 같다.


위키피디아님이 도메인 모델에 대한 정의(http://goo.gl/Bna2U)도 다음과 같이 내려주셨다.

A domain model in problem solving and software engineering is a conceptual model of all the topics related to a specific problem. It describes the various entities, their attributes, roles, and relationships, plus the constraints that govern the problem domain. It does not describe solutions to the problem.


소프트웨어 공학에서 도메인 모델이란 특정 문제와 관련된 모든 주제의 개념 모델이다. 도메인 모델은 다양한 엔티티, 엔티티의 속성, 역할, 관계, 제약을 기술한다. 문제에 대한 솔루션을 기술하지 않는다.

예전에 얼핏 봤던 방법론이 요구사항 분석 과정에서 UML로 개념 모델을 만들었는데 이 때의 개념 모델이 도메인 모델에 해당된다. 유스 케이스나 유저 스토리 같은 것이 도메인의 동적 측면을 보여준다면, 도메인 모델은 도메인의 정적 구조를 보여준다.


도메인 모델은 지식을 공유하고 소통하는 도구로 사용하기에 적합하다. 요구사항 분석 과정에서 분석가(기술팀)는 구축한 도메인 모델을 통해 자신이 올바르게 이해했는지 확인할 수 있고, 반대로 업무 전문가들도 자기들끼리 의견을 맞추는데 도메인 모델이 도움이 된다.


아키텍처에서 도메인 레이어의 결과물을 도메인 모델로 부르기도 한다. 프리젠테이션 레이어, 어플리케이션 레이어, 도메인 레이어, 인프라스트럭처 레이어와 같은 구조에서, 도메인 레이어는 도메인의 개념, 도메인의 정보, 도메인의 규칙을 표현하는 책임을 진다.


예전에는 분석가(컨설턴트)라는 사람들이 이런 도메인 모델을 만들어서 구현 담당자에게 넘겨주고 떠나곤 했다. 이를 넘겨 받은 구현자들은 도메인 모델을 다시 구현 모델(즉, 소프트웨어 설계)로 변환하는 과정을 거친 뒤에 구현을 진행했다. 그런데 여기서 문제는 도메인 모델이 구현 모델로 넘어가는 과정에서 많은 도메인 지식들이 유실되면서 실제 도메인 전문가가 요구하는 소프트웨어가 만들어지지 않는다는 것이다. 게다가 모든 요구사항은 프로젝트가 진행되는 동안 완성되어 나가기 때문에 구현 과정에서 발견되는 도메인에 대한 통찰이나 개념들이 도메인 모델에 다시 반영되지 않는 문제도 있다.


도메인과 구현 사이의 불일치는 (프로그래머와 도메인 전문가 사이의) 불필요한 해석 과정을 야기하고, 이는 잘못된 소프트웨어를 만드는 원인이 되기도 한다. 이런 불일치를 해소하기 위한 노력 중 하나가 도메인 주도 설계Domain-Driven Design이다. DDD는 도메인 모델의 적용 범위를 구현까지 확장하는데, 이를 통해 도메인 지식이 구현 코드에 반영되도록 하고 있다.


------

  • 조영호 님 : 도메인은 저희 입장에서 소프트웨어를 개발하는 대상 영역정도로 생각해도 무방합니다. 택시 앱을 만든다면 택시 기사님께 콜을 하고, 탑승하고, 요금을 지불하는 전 과정이 도메인이 됩니다. 물론 프로젝트를 할 때는 이 중에서 소프트웨어로 개발될 범위로 한정해서 범위를 좁하게 됩니다. 이렇게 개발 대상과 범위를 간단히 도메인이라고 봐도 무방할 것 같습니다. 도메인 모델이란 도메인을 모든 사람이 동일한 관점에서 이해할 수 있고 공유할 수 있도록 단순화시킨 것이라고 보시면 됩니다. 이게 꼭 클래스 다이어그램의 형식으로 표현될 필요는 없지만 객체지향 프로그래밍을 하는 경우에는 일반적으로 클래스 다이어그램의 표기법을 사용해서 도메인 모델을 정리하는게 여러모로 유용합니다. 이렇게 하는 이유는 객체지향 패러다임에서 사용하는 유사한 기법에 기반하는게 코드와 모델을 유사한 형태로 유지하는데 이롭기도 하고 일단 도메인 모델을 이해하면 그 모델을 기반으로 코드를 쉽게 이해하고 수정할 수 있기 때문이죠. 다른 패러다임인 경우에는 그 패러다임에서 구현하기 쉬운 형태로 작성하면 되겠죠. 마지막에 아키텍처 상에서 말하는 도메인 모델은 마틴 파울러가 PEAA에서 언급한 것으로 도메인 레이어를 객체지향적으로 구현하는 패턴을 가리키는 용어입니다. 즉 패턴의 일종이고 원래의 도메인 모델과는 약간 거리가 있습니다.
  • 박성철 님 : 도메인 모델이란 용어 자체만 보면 문제 영역을 개념적으로 모델링한다는 평범한 의미인데 이 용어가 OOA/D 분야에서 사용되었기 때문에 객체 모델링이 함의된 것 같습니다. 흔히 도메인 모델이라고 하면 정적 데이터 요소를 표현하는 것으로 국한하는 것 같은데 동적인 요소(예를 들어 유즈 케이스)까지 고려가 되어야 할 것 같습니다.


  1. kayano 2015.04.14 18:06

    정말 블로그처럼

+ Recent posts