블로그 이미지
평범하게 살고 싶은 월급쟁이 기술적인 토론 환영합니다.같이 이야기 하고 싶으시면 부담 말고 연락주세요:이메일-bwcho75골뱅이지메일 닷컴. 조대협


Archive»


 

'아키텍쳐 /Domain Driven Design'에 해당되는 글 5

  1. 2009.07.07 Domain Driven Design - Modeling (3)
  2. 2009.07.07 Domain Driven Design이 잘 정의된 문서
  3. 2009.07.06 비지니스 도메인에 대한 공유 문제?
  4. 2009.07.04 DDD (Domain Driven Design) - Context Continuous Integration (3)
  5. 2009.07.03 DDD
 

Domain Driven Design - Modeling

아키텍쳐 /Domain Driven Design | 2009.07.07 23:02 | Posted by 조대협
직업이 직업인 만큼 요즘 Domain Driven Design 에 대해서 심도깊게 보고 있습니다.
아키텍쳐 분석 설계와 프로젝트 진행에 있어서 가장 중요한 것중의 하나가 "고객의 요구 사항을 어떻게 파악할것이며 이를 어떻게 모델화 하느냐?" 입니다. 모델 자체가 목적이 아니라 모델이라는 공통된 언어를 사용하여 고객과 소통을 하고 요구 사항을 가급적 정확하게 도출하여 나중에 미도출된 요구사항이나 잘못 분석된 요구사항이 없도록 하는 것이 중요한 포인트 중에 하나입니다.

그리고 프로젝트중에는 프로젝트 구성원, 고객, 각기 다른팀, 비지니스 전문가, 분석가, 아키텍트들간의 생각하고 있는 개념이나 목표가 서로 다른 경우가 있습니다. 그래서 시스템을 구축해놓고 나면 결국 각자가 생각한것과 다른 결과물이 나오거나 구현이 서로 기대했던 바와 달라서 모듈간 통합에서 문제가 발생하거나 많은 비용과 자원이 소요되는 경우가 있습니다.

이런 모든 문제의 공통적인 원인은 프로젝트의 구성원 자체가 현재 프로젝트의 목적,현황,디자인,업무,각자의 역할등 프로젝트에 대한 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같은 곳에 유지 하는 것이 좋다. (엑셀로 만들어놓고 공유 폴더에 넣어놓는것은 거의 효용성이 없다.)

모델의 분리
전체적인 도메인 모델이 완성이 되었으면 도메인 모델을 세부 모델로 나누도록 한다.
큰 모델에는 전체적인 흐름과 기능에 대해서 서술되어 있으며, 디테일한 내용을 다루게 되면 모델 자체의 크기가 커져서 그 내용을 이해하기가 어려워지면서 모델로써의 효용성이 떨어진다. 또한 각각의 개발팀의 관심사는 자신이 속한 부분의 모델이기 때문에,각 팀에 모델을 나누어주기 위해서라도 모델을 분리하는데, 이 분리하는 기준을 DDD에서는 Boundary Context라고 한다. 업무의 독립단위 또는 프로젝트팀 단위로 나누도록 한다. 이때 타업무(타 도메인 모델과) 연관성이 있을 경우 이를 포함해서 나눠서 나뉘어진 모델 안에서 다른 업무와의 연계성을 파악할 수 있도록 한다.

모델을 나누면서 중요한것이 메인 모델과의 추적성을 부여하는 것인데. DDD에서는 이 방법으로 Context Map이라는 기법을 소개한다. 상위모델의 모듈이 어떤 모델로 분리가 되었는지를 명시적으로 표현하는 방법이다. UML의 Use case모델에서는 흔히 각 use case를 sub usecase diagram으로 나누면서 관계에 대한 추적성을 부여하거나 Use case의 이름에 Numbering을 해서 1. Order 1.1 Billing 1.2 Submit Order식으로 Sub Number를 붙여서 모델간의 상하위 추적성을 제공하기도 한다.
 DDD에서 Context Map이라는 용어를 궂이 사용한 이유는 Numbering을 사용할 경우 텍스트 기반의 추적성 부여이기 때문에 추적성 자체는 살아 있을 수 있지만 가시성이 떨어진다. Context Map이라는 단일의 하나의 다이어그램을 작성함으로써 가시적으로 상위 모델이 하위모델로 어떻게 연결(분리)되는지를 표현함으로써 Context의 전이가 어떻게 되는지가 표현될 수 있다.

하위모델간의 공통 모듈 처리
하위 모델간의 공통적으로 사용하는 모듈이 존재할 수 있는데, 이런 모듈의 변경은 두개의 프로젝트에서 동시에 사용하기 때문에 변경이 있을 경우 두개의 시스템에(업무 모듈)에 동시에 영향을 줄 수 있다. 
이렇게 동시에 두개 이상의 모델에서 공유되는 모듈을 DDD에서는 Shared Kernel이라고 하고, 연관되는 프로젝트 팀이 같이 설계하고 변경에 대해서 서로 협의하여 반영하도록 가이드 하고 있다.
실제 프로젝트에서는 사실 쉽지 않은 일인데, 이러한 공통 모듈에 대한 관리와 교통 정리는 AA (Application Architect)가 관여하여 분쟁이 있을때 조정을 해줄 수 있어야 하며, 이 Shared Kernel에 대한 Model은 항상 Wiki와 같은 Live Document에 최신 상태로 유지되어야 한다.
DDD에서는 이러한 두개 이상의 모델의 의존성에 의한 오류 방지책의 하나로 Continuous Integration (CI)를 권장하고 있다. 본 블로그에서도 Hudson이나 ALM을 통한 CI의 개념을 수차례 설명했다.
간단하게 설명하자면 CI는 지속적으로 빌드와 테스트를 자동화하여, 변경 내용에 의해서 기존 코드가 오동작하는 것을 조기에 발견한다.
즉 Shared Kernel 에 대해서 A팀이 구현을 변경했을때, 이 변경이 기존 동작 방식에 영향을 끼치면 B팀의 CI Test과정에서 모듈이 변경이 되서 기대했던 대로 작동을 하지 않음을 발견한다.

결론
대략 DDD의 Context 기반의 모델링 기법을 정리해보면 이렇습니다.
사실 그이에도 하위 모델간의 관계와 서로간의 의존성을 최소화 하는 여러 기법들을 DDD에서 소개하고 있습니다.
Anticorruption Layer(Facade를 이용하여 완충 레이어를 두는 방법, ESB의 Mediation이나 EAI 패턴과 유사하지요.)
Open Host Service (인터페이스를 추상화된 서비스 계층으로 외부에 서비스한다는 개념인데, SOA의 서비스 개념과 유사합니다.)
Customer Supplier Teams (단방향 의존성을 갖는 경우에 인터페이스 하는 방법에 대한 정의인데, EAI에서 이미 소개되고 사용되는 방법이구요.)
그외에 여러가지가 있는데, 대부분 설계 방법에 관련된것이고, 위에서 소개했던 것과 같은 분석과 모델링 방법에 대한것은 아니라서 자세하게 소개하지는 않았습니다.

디자인 패턴과 설계 방법론에 대해서는 이미 다른 곳에서도 많이 소개된 바가 있고, 도메인 (업무)기반의 설계 방법도 사실 OOP 이전부터도 존재했기 때문에 별다를것이 없지만, DDD에서 주목할만한 것은 모델링에 대한 원래 목적을 뒤돌아보고 그에 대한 접근 방법을 정리했다는 것에 주목하고 싶습니다.


저작자 표시
신고

PDF로 무료 다운 받을 수 있습니다.

오리지널 책인 Erik eVan의 DDD보다 내용이 정리되어 있고 무엇보다 영어가 좀더 쉬워서 이해하기가 좋습니다. 참고하세요.

저작자 표시
신고
DDD를 읽는중에 재미있는 구절이 하나 있어서 적어놉니다.

==
In the old waterfall method, the business experts talk to the analysts, and analysts digest and abstract and pass the result along to the programmers, who code the software. This approach fails because it completely lacks feedback. The analysts have full responsibility for creating the model, based only on input from the business experts. They have no opportunity to learn from the programmers or gain experience with early versions of software. Knowledge trickles in one direction, but does not accumulate.

Other projects use an iterative process, but they fail to build up knowledge because they don't abstract. Developers get the experts to describe a desired feature and then they go build it. They show the experts the result and ask what to do next. If the programmers practice refactoring, they can keep the software clean enough to continue extending it, but if programmers are not interested in the domain, they learn only what the application should do, not the principles behind it. Useful software can be built that way, but the project will never arrive at a point where powerful new features unfold as corollaries to older features.

==
상당히 현실적인 이야기 같은데, 전통적인 Water-fall model에서는 시스템을 분석하는 사람이 분석업무 전문가와 함께 분석을 끝내기 때문에, 개발에 대한 경험이나 기술적인 내용이 반영이 되지 않기 때문에, 문제가 되고,
Iterative 한 Agile 방법론에서는 개발자 중심으로 이루어지되, 각 Iteration별로 해야할일에 대해서만 Scope를 가지기 때문에, 전체를 보지 못하고, 시야가 좁아지는 문제점이 생깁니다.

양쪽다, 비지니스 도메인에 대한 이해가 비지니스에서 개발단으로 공유되지 못하는 문제를 가지는 원인들입니다.

사실 어떻게 해결해야 할까는 더 읽어보고 고민해봐야 하는 일이지만 맞는 내용 같습니다.
특히 Agile에 대한 내용은 뜨끔 하더군요. Scope를 잘라서 iteration단위로 움직이는 것은 좋지만, 전체 그림을 보는 것을 놓쳐 버리는 실수를 범할 수 있기 때문입니다.

그런데, 전체 구성원들이 비지니스 도메인에 대한 전체적인 이해를 한다는게 많은 시간과 노력이 필요할텐데, 도대체 얼마만큼 범위와 그리고 어느정도 시간을 투자해서 이해를 해야하는건가 생각해볼만한 이슈입니다.
신고
오전에 우리딸 먹을 아빠표 맘마 만들어놓고, 우리식구 새로운 보금자리를 구입해놓고 인터리어 공사때문에, 아파트 76세대를 돌면서 인테리어 공사 동의서에 싸인을 받으러 다녀왔습니다.
메론 한손에 들고 말이지요. 51세대(70%)에 받아야 한다고 해서 어젯밤부터 부지런히 발품을 팔았습니다.

그런데 와이프가 친구가 화장실 타일을 이쁜것을 무료로 몇달후에 주겠다고 해서, 자재비 아끼기 위해서 화장실 공사를 나중에 다시 또 해야 할것 같습니다. 그래서 다시금 76세대를 돌아야 하는 사태가 생길지도 모르겠습니다.

대충 정리하고 들어오니 12시군요. 와이프는 아직 직장에서 돌아오지 않았고, 15개월된 딸은 기분좋게 낮잠을 자고 있어서 오랜만에 주말오전에 다만 몇십분이나마 개인 시간을 가지고 있습니다. DDD에 관심만 가지고 있다가 우연하게 다른분 포스트에서 Context Continuous Integration 에 대한 개념을 보게 되었습니다.

개념 자체는 프로젝트에 속한 모든 인원들이 Context 를 공유한다는 것이고, 이 Context 에 대한 통합을 지속적으로 한다는 것입니다. Context의 개념은 조금더 공부해 봐야 알겠지만 제가 이해하는 바로는 다음과 같은 내용입니다.

  • 프로젝트의 목표
  • 각 모듈별의 기능
  • 용어 (대외계,대내계,계정계,동기화,분할거래,전달보장,순차거래,서비스 등등)
  • 팀별 역할

한 마디로 정리하자면, "누가 무엇을 언제 어떻게 할것인가"에 대한 공감대를 지속적으로 공유하여 서로 같은 목표와 같은 생각으로 프로젝트를 진행하는 개념입니다.

"아! 이거다" 하는 생각이 들정도로 공감이 가는 내용이었는데, 실제 프로젝트에서도 보면, 서로 딴생각 다른 목표로 진행되는 경우가 많습니다. 그러다 보니 "여기는 A팀 역할 아니었냐?" "우리는 B팀으로 알고 있었다."와 같은 상황속에서 역할의 공백이 생기거나, "이 시스템 이렇게 동작하기로 되어 있는것 아니었어? 여기에 맞춰서 설계했는데..." "그게 아니니라 ABCD로 동작한다고 했었잖아요." 와 같은 문제가 생기게 됩니다. 실제 빈번하게 발생하는 상황이지요. 특히나 다수나 여러팀이 협업하는 경우에 많이 생깁니다.

 이런 문제를 해결하는 방법은 소통이 가장 좋은 방법입니다. 끊임없이 만나서 이야기하고 서로의 생각의 차이점을 조율하고 하나의 Context를 가지는 방법입니다.

 그외에도 Boundary를 정하는 방법이나 비지니스 적으로 시스템을 접근하는 방법등 좋은 내용이 많네요.
http://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215/ref=sr_1_1?ie=UTF8&s=books&qid=1246678215&sr=8-1

꼭 시간내서 읽어봐야 겠습니다.
요즘 모 출판사에서 책을 마음것 볼 수 있도록 후원을 해주시고 계셔서 읽어야 하는 책만 쌓여 갑니다. Thomas Erl 의 SOA Design Pattern에도 좋은 내용들이 많던데요.. 조금더 부지런해져서 읽어놔야 겠습니다.

저작자 표시
신고

DDD

아키텍쳐 /Domain Driven Design | 2009.07.03 11:00 | Posted by 조대협

DDD를 잘하기 위한 요구사항이란다.
==

http://www.infoq.com/articles/ddd-in-practice

Let's look at some of the other factors that are required for implementing a domain model.

  • The team should have regular access to business domain subject matter experts.
  • IT team (modelers, architects, and developers) should possess good modeling and design skills.
  • Analysts should have good business process modeling skills.
  • Architects and developers should have strong Object Oriented Design (OOD) and Programming (OOP) experience.
==
이정도 전문성이 있는 사람들이 모여 있다면 DDD가 아니더라도 프로젝트가 잘되지 않을까?
저작자 표시
신고