얼마전 이대엽님이 도메인 주도 설계 (Domain Driven Design) 라는 명서를 번역해 주셨습니다. 저 역시 구매를 했었고, DDD가 가져오는 철학이나 사상은 정말 훌룡합니다.
왜 이런 명서가 이제 번역될수 밖에 없는지 현실을 알고 있지만, 정말 슬픕니다.
POSA나 DDD와 같은 명서들은 번역을 한다는 것의 거의 희생에 가깝습니다.
사실 역자 입장 에서는 적절한 어휘 선정과, 국내 개발자의 시선에 맞게 레벨을 조정하기 위해 각주를 다는등 여러가지 노력이 필요합니다.
또한 책이 많이 팔릴지도 의문이고, 이미 읽을만한 분은 다 읽었다고 생각이 들고, 나의 안티를 양성하지 않을까 고민이 됩니다.
실례로, 몇몇 출판사를 통해 “명서를 왜 이렇게 번역했느냐?”라며 여러가지 공격을 당한 사례들을 종종 들었기에 쉽게 움직이지 못하는 것도 사실입니다.
이러한 상황에서도 DDD가 이 세상에 나오게 해주신 이 대엽님과 여러 고생해 주신 분들에게 감사를 드립니다.
다시 본론으로 돌아와 DDD는 고객과 개발자/아키텍트 간에 대화를 나눌수 있는 좋은 도구입니다.
패턴 계의 철학을 생각해 보면, 모든 상황에 만능인 솔루션은 없다. 단지 상황에 맞는 해결책이 있다는 것을 생각해 볼 필요가 있습니다. 그러기에 해당 Context들이 대부분 도메인과 밀접한 연관이 있고, DDD의 초안이 PLoP 에서 첫 데뷔를 했기 때문에 역시 그 본류는 패턴의 철학과 맞 닿아 있는 방법입니다.
그럼 DDD를 프로젝트에 적용하기 이전에, 고려해야 할 것들 이야기 해보고자 합니다. 어떠헌 프로세스, 툴들에게도 동일하게 적용된느 철학입니다. 맹목적인 추종보다 결국 상황에 맞는 솔루션이라는 것을 기억해 주셔야 됩니다.
이번 저자 워크샵은 정말 힘든 강행군의 연속이었습니다.
PLoP 2011의 의장인 Lise Hvatum 과 2일에 거쳐 패턴을 같이 다듬었습니다. 사실 이번 PLoP에는 저희가 바쁜 일정에 논문을 잘 쓰지 못해서 논문을 같이 다듬는 Writing Group으로 배정을 받았는데, 오히려 많은 것을 배운거 같습니다.
같이 논문을 써준 김 지원님이 같이 간 덕분에 외롭지 않고, 이래 저래 정리한 내용도 2배로 늘어났습니다. 
결과적으로 좀더 Clear하게 그리고 Simple 하게 전체적으로 패턴을 바꾸었습니다. 첫째날 차 유리가 깨지고 지원이가 노트북을 읽어 버리는 바람에 사고 수습하느라 하루가 날라가 버리고, 남은 2일동안 강행군을 펼쳤고, 마지막날 새벽 4시에 겨우 마쳐서 최종본을 보냈슴니다.
지원가 맘고생도 많았지만, 이 잃어버린 노트북만 아니였어도.. 이렇게 고생을 하지않았을 텐데… 마지막날에 발표한 자료가 pdf 로 변환하면서 몇몇이 깨져버려 이래 저래 고생을 가장 많이한 PLoP 입니다.
Lise에게 보여주니, 새벽 4시에 온 메일을 보고 놀랐다고,정말 용감했다고 하더라구요! 좀더 명확하고 간결해졌다고 피드백을 받았습니다.
저자 워크샵
저자 워크샵이 무엇인지 모르시는 분은 제가 일전에 포스팅 한 저자 워크샵 데모 포스트를 보시고읽어보시면 좋을듯 합니다.
(중앙에 있는 분이 PLoP 11 Chair이자 , 저희 논문 Shepherd였던 Lise Hvatum , 그리고 오른쪽에 있는 분이 AsianPLoP의 리더이자, 와세대 대학의 조교수이신 Hironori Washizaki 입니다.)
실제 저희 워크샵에서 받은 내용을, 지원이가 잘 정리해 주었습니다. 추후 mp3를 듣고 더 업데이트 할 생각입니다.
Architecture 101 