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


Archive»


 
 

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가 아니더라도 프로젝트가 잘되지 않을까?