아키텍쳐 분석 설계와 프로젝트 진행에 있어서 가장 중요한 것중의 하나가 "고객의 요구 사항을 어떻게 파악할것이며 이를 어떻게 모델화 하느냐?" 입니다. 모델 자체가 목적이 아니라 모델이라는 공통된 언어를 사용하여 고객과 소통을 하고 요구 사항을 가급적 정확하게 도출하여 나중에 미도출된 요구사항이나 잘못 분석된 요구사항이 없도록 하는 것이 중요한 포인트 중에 하나입니다.
그리고 프로젝트중에는 프로젝트 구성원, 고객, 각기 다른팀, 비지니스 전문가, 분석가, 아키텍트들간의 생각하고 있는 개념이나 목표가 서로 다른 경우가 있습니다. 그래서 시스템을 구축해놓고 나면 결국 각자가 생각한것과 다른 결과물이 나오거나 구현이 서로 기대했던 바와 달라서 모듈간 통합에서 문제가 발생하거나 많은 비용과 자원이 소요되는 경우가 있습니다.
이런 모든 문제의 공통적인 원인은 프로젝트의 구성원 자체가 현재 프로젝트의 목적,현황,디자인,업무,각자의 역할등 프로젝트에 대한 Context 에 대해서 제대로 이해하지 못해서 발생하는 문제입니다. 어떻게 보면 Communication의 문제입니다.
프로젝트내에서 이 Context 가 제대로 공유된다면 같은 생각과 같은 현황 파악으로 인해서 프로젝트가 잘못된 방향으로 흘러가는 것을 상당 부분 예방할 수 있습니다.
이러한 관점에서 시작된것이 Domain Driven Design 인데, 기본적으로 도메인(업무 또는 현업)과 개발팀간 그리고 각기 다른 업무 개발팀간의 의사소통 방법과 소프트웨어 디자인 방법에 대해서 설명하고 있습니다. 소프트웨어 디자인 방법이나 패턴에 대해서는 다른 좋은 방법론도 많기 때문에 눈에 확 들어오지는 않았습니다만, 제가 주목하는 것은 어떻게 서로 Context를 공유할것이며, 이를 어떻게 모델링을 할것인가에 대한 기법이 참으로 흥미롭습니다.
그림으로 정리를 해보도록 하지요.
메인 모델의 작성
먼저 구축하고자 하는 시스템이 하는 비지니스 업무를 파악하는 것이 첫단계 인데. 실제 비지니스가 어떻게 돌아가는지를 다이어그램등의 모델을 이용해서 표현한다. 이때 다이어그램은 UML Class Diagram이 되도 좋고, BPM 또는 Use case Model 모두 좋다. 무엇이든 간에, 업무 전문가와 개발팀간에 가능한한 빠르고 명확하게 의사 소통을 할 수 있는 것이면 무방하다.
업무전문가와 모델링을 하는 사람 (개발자,분석가 또는 아키텍트 이하 모델러라고 지칭하겠다.) 은 같은 언어를 사용해야 한다. 이를 DDD에서는 유비쿼터스 언어라고 하는데,
예를 들어 "메세지"를 표현하는 방법도 금융 업무에서는 "원장", 또는 "전문" 이라는 용어를 사용하고, 개발자들은 "메세지", "PAYLOAD" 등 여러가지 표현을 사용한다. 또 대내,대외계 거래, 계정계,정보계 시스템, 여신 거래,상품 거래 등의 비지니스 업무 용어, 개발쪽에서는 메시징,큐잉, MEP(Message Exchage Pattern) 등 기술 위주의 언어를 사용한다.
DDD에서는 이와 같은 업무 분석과 모델링에서의 소통을 서로 공통된 언어를 사용하도록 하는데, 업무 위주의 언어를 사용해야 한다.
특히 용어가 정의될때 마다 Glossary (용어 사전)에 이를 기록하고 명확하게 정의를 함으로써 추후 또는 다른 사람들도 공통된 언어를 사용할 수 있도록 한다. 예를 들어 중간에 개발자가 새롭게 들어오거나 다른 기반 지식을 가진 아키텍트가 들어왔을때, 각종 산출물이나 회의시간에서 용어가 통일 되지 않아서 혼선이 이루어지는 경우가 많다. 구두로 용어에 대해서 설명하는 것도 가능하겠지만 프로젝트의 규모가 커지면서 많은 사람들이 참여하고 산출물의 양이 많아질때는 점점 통제 불가능 상태로 가기 때문에, Glossary를 사용하는 것이 좋고, 이 Glossary는 항상 쉽게 찾아볼 수 있도록 WIKI같은 곳에 유지 하는 것이 좋다. (엑셀로 만들어놓고 공유 폴더에 넣어놓는것은 거의 효용성이 없다.)
전체적인 도메인 모델이 완성이 되었으면 도메인 모델을 세부 모델로 나누도록 한다.
'아키텍쳐 > Domain Driven Design' 카테고리의 다른 글
Domain Driven Design - Modeling (3) | 2009.07.07 |
---|---|
Domain Driven Design이 잘 정의된 문서 (0) | 2009.07.07 |
비지니스 도메인에 대한 공유 문제? (0) | 2009.07.06 |
DDD (Domain Driven Design) - Context Continuous Integration (3) | 2009.07.04 |
DDD (0) | 2009.07.03 |
댓글을 달아 주세요
좋은글 감사합니다
DDD 에 대하여 간단하면서도 쉽게 설명해주셨네요.
좋은글 잘 읽었습니다.
하지만 DDD에서 제일 중요한 핵심인 aggregate boundary와 repository에 대한 아무 설명이 없네요?
설명해주신 bounded context는 모델이 너무 커 졌을때만 해당이 되지 보통 context map도 필요 하지 않습니다. 그리고 분리를 하지 않는것이 Ubiquitous Language를 만드는데 도움이 되지 않나 생각됩니다.
좋은 글 잘 읽었습니다. DDD를 ITSM이나 MDA와 결합한 사례가 있는지 관심이 많은데 찾기는 쉽지 않네요.
MIS뿐 아니라 제조시스템도 ITSM과 같은 repository로 정보를 모으고 DSL과 같은 공통언어를 통해 대화하고 MDA 기반으로 소스를 유지보수해야 한다는 생각인데 갈 길이 머네요. 앞으로도 좋은 글 계속 부탁드립니다.