|
원서를 보려다 아무래도 한글 책을 빨리 읽을 수 있을 것 같아 사 보았지만 역자가 과연 내용을 이해하고 번역을 한 것인지 계속 의구심이 들만큼 내용을 이해할 수가 없다. 가능하면 원서를 읽는 편이 좋을 것 같다. 그리고 이 책과 같이 대중성이 있는 책들은 내용을 모르는 사람이라면 가능한 번역도 하지 않는 것이 좋겠다. 이런 식으로 번역서를 내버리면, 다른 훌륭한 역자가 번역할 기회를 잃게 되며 동시에, 관련 주제에 대하여 다수의 독자가 거부감을 느끼게 된다. |
|
읽는 동안 참, 괴롭기만 했던 책이었다. 보통 왠만한 전공서적도 3일 내외로 독파 하던 나도, 이책은 읽기가 너무 부담 스러웠다. 원서의 내용은 모르지만, 자주 사용하지 않은 용어가 너무 많았고, 문장을 독해 하는데 신경이 너무 많이 쓰였다. 10페이지 읷는데 보통 한시간씩 걸렸고, 어떤 땐, 한 페이지를 읽는데 한시간이 걸리기도 했다. 게다가 아직도 내용의 절반을 채 이해하지 못했다. 그래도, 다행이 이해가 되는 부분들은 개발에 대한 새로운 영감이 주었다. 주 된 내용은 아키텍트를 구성하기 위한 지침과 교훈들을 패턴언어로 설명한 책이라고 보면 된다. 모 책 싸이트에서 상위에 랭크 된 책이길래, 충동적으로 구매 했지만, 아키텍트를 구성하기 위한 지침들은 매번 새롭기만 했다. 그동안 내가 공부한 책들은 주로 프레임워크나 각종 기술에 대한 것들이었다면, 이 책은 아키텍트에 대한 원칙을 포괄한 내용들이 주류를 이룬다. 간혹 JAVA로 된 코드도 조금 있지만, 코딩 방법에 대한 내용이라기 보다는 좀 더 근본적인 이론이 주 된 내용이다. 이론의 골자는 바로 DOMAIN 이다. 하지만, 정작 책에서 DOMAIN에 대한 용어정의가 되어 있지 않은 것 같다. DOMAIN과 모델의 차이점 등에 대해 명확한 설명이 없어서 너무 추상적으로 받아들여 진다 해야 할까? 그나마 내가 반이라도 이해 할 수 있었던 이유는 그동안 쌓아온 경험과 배경지식이 있어서 였던 것 같다. 이해한 바에 따르면, 개발자는 기술 패러다임에 갇혀 소프트웨어를 설계하고 만들어 가다가 복잡한 소프트웨어를 만드는 실수를 해버리곤 한다. 나만해도 이제것 기술연마에 너무 많은 공을 들여왔던게 사실이다. 하지만, 그보다 더 근본적인 바탕에는 DOMAIN이 존재하고, 이 DOMAIN을 중심으로 명세를 정의하고 구조를 만들어야 한다는 것이 일부 내용이다. 그리고 구조는 각 모델에 따라 영역을 명확하게 구분해야 하고, 영역과 영역사이에는 서비스 영역을 두어야 한다는 것, 정작 기술은 캡슐화를 통해 도메인과 분리해서 적용해야 한다 등등... 꾀나 논리적이고 명확한 설계 원칙이 담겨 있었다.(해당 내용은 책의 극히 일부 내용에 불구하다. 더 자세한건 책에서 직접 보시길) 사실, 그동안 개발을 하면서 지나치게 프레임워크에 심취해서, 도메인 객체에 대해서는 그 중요성을 과소평가 했던 것 같다. 오히려 도메인 입장에서는 각 계층마다 존재하여 어디서든 이용되고, 가공되데도 불구, 지나치게 단순해서(getter setter만 있는), 현실 반영이 안된 객체로 만들어 놨던 것 같다. 그 탓에 여러 계층과 설계가 어지럽고 괴상하게 만들어 졌다는 것을 깨달았다. 프레임워크를 쓰든, 설계를 새로이 하든지 간에 가장 먼저 고려되어야 할 것은 DOMAIN이고 이를 바탕으로 모델과 각계층과 영역을 만들어 나아가야 한다. 그리고 이 DOMAIN을 통해서 업무 전문가와 협의를 해야 한다. DOMAIN을 통하면 현실과 객체간의 의사소통의 괴리감을 줄이고 점진적으로 소프트웨어를 발전시킬 수 있다. 모든것을 DOMAIN 중심으로 생각하라! 이 명료한 한문장이 기존에 내가 해왔던 개발 방법에 대한 패러다임을 바꾸는 원동력이 될 것 같다. 이 책의 지침들만 모두 이해하고 실천 할 수 있다면, 아키텍처로서 한걸음 나아가는 것이 어렵지 않을 것 같다는 생각도 든다. 기존엔 도메인은 속성만 가진 단순한 객체로만 만들었다면, 이 책에서는 각 도메인들이 서로 의존관계를 맺는데 주안점을 두고 있다. 이책을 읽기전에 배경지식이 많이 필요한데 그 목록은 다음과 같다.
- 객체지향. UML - 디자인 패턴 - 리팩토링 - 테스트 주도 개발 방법론 - 분석패턴 - 지속적인 통합 이중에서 객체지향, 디자인 패턴, 리팩토링에 대한 선행 학습은 필수다. 그리고 무엇보다. 실제 프로젝트를 해보며 얻은 경험이 더 중요하다. 다행이 나는 위의 목록들에 대해 선행학습이 이미 되어 있었지만, 경험적 측면에서 많이 부족했던 것 같다. 내가 이해하지 못한 절반은 경험적으로 이해해야 받아들여질 부분들인 것 같다. 아무래도 이 책은 두고 두고 수시로 읽어 봐야 할 것 같다. 인터넷의 일부 자료들의 경우 '도메인 주도 설계'를 'Rich Domain 개발'과 혼돈을 하는 모양인 것 같았다. 아니 설계와 개발의 차이를 이해하지 못한 것 같다. 그리고 일부 블러거의 설명은 너무 주관적이거나 오해에서 비롯하여 잘 못 기술 된 내용도 많았다. 어디까지나 코드화 된, 예제에 매달리는 모습들이 었다. 이책은 도메인이 Rich하냐 Simple하냐에 대한 설명은 전혀 되어 있지 않다. 어디까지나 현실을 기반으로 도메인을 어떻게 객체화 하느냐의 문제가 중요 한 듯 하다. 덧붙여, 도메인이란 현실과 객체 사이의 가교적 의미라고 볼 수 있겠다. 물론 최근에 와서 주목 받고 있는 'Rich Domain 개발' 또는 '도메인 주도 개발론'이 이 책에서 말하는 '도메인 주도 설계'에서 파생된 건 맞다. 하지만, 그건 패턴화 또는 프레임워크화 된, 일부 사례이지, 도메인 주도 설계의 전부를 보여주는 거라 할 수는 없다. 한번 더 강조하지만, 개발과 설계의 차이를 명확하게 인식하는 것이 중요 하다고 본다. 이 책은 설계에 대한 책이다. 마지막으로 이책은 특정 기술에 대한 책이 아니며, 도메인 설계를 위한 방법과 지침들에 대한 풀이로 나열 된 책이다. 패턴언어로 기술되어 있고, 도메인을 풍부하고 유용하게 쓰는 방법을 예시하고 있다. 이를 실천하는 근본에는 리팩토링과 디자인 패턴이 중요하며, 기왕이면, 다양한 도메인을 다뤄본 경험이 토대가 되어야 이해하는데 도움이 될 것이다. |
|
갈수록 복잡해져가는 소프트웨어 개발에 있어서 복잡성의 관리는 매우 중요한 과제입니다. 이러한 복잡성의 관리에 있어서 현재까지 나와있는 소프트웨어 공학중 가장 뛰어나다고 평가받는것이 이 도메인 주도 설계 (Domain-Driven Design : DDD) 입니다. 어려운 주제라 번역이 쉽지 않을듯 했는데, 다행이 이대엽씨가 번역을 해 주셨네요. 다른분이 리뷰에 적어주셨는데 이 책을 읽기전에 도메인을 비롯해 여러 관련 용어 개념을 먼저 잡아놓고 나서 읽는것이 전체적인 내용을 이해하는데 많은 도움이 됩니다. 마틴파울러가 쓴 Patterns of Enterprise Application Architecture를 보면 이 책에서 다루는 주요 개념들에 대해 알기쉽게 설명하고 있으므로 먼저 읽어 두길 추천합니다. 참고로 이 책의 저자가 직접 작성한 코드 샘플이 웹상에 공개되어 있으니 책의 내용과 참고하면서 보시기 바랍니다. http://dddsample.sourceforge.net/ |
|
"코드와 그것의 기반이 되는 모델이 긴밀하게 연결되면 코드에 의미가 부여되고 모델과 코드가 서로 대응하게 된다. 코드가 모델을 표현할 때 객체지향 설계가 완성된다."
객체지향 설계에 대한 마침표를 찍을 수 있는 책.
책의 의미를 하나씩 하나씩 내것으로 소화할수록 코드가 나를 닮아가는 것에 즐거움을 느끼게 해주는 책.
개발이 재미있어지고, 모델링이 즐거워 지는 책.
번역해주신분에게도 감사하지만 토비의 스프링을 통해 이 책을 접하게 되었으므로 토비님에게도 감사.
|