DDD (Domain Driven Design) - Context Continuous Integration

오전에 우리딸 먹을 아빠표 맘마 만들어놓고, 우리식구 새로운 보금자리를 구입해놓고 인터리어 공사때문에, 아파트 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에도 좋은 내용들이 많던데요.. 조금더 부지런해져서 읽어놔야 겠습니다.