얼마전 이대엽님이 도메인 주도 설계 (Domain Driven Design) 라는 명서를 번역해 주셨습니다. 저 역시 구매를 했었고, DDD가 가져오는 철학이나 사상은 정말 훌룡합니다.

왜 이런 명서가 이제 번역될수 밖에 없는지 현실을 알고 있지만, 정말 슬픕니다.

POSA나 DDD와 같은 명서들은 번역을 한다는 것의 거의 희생에 가깝습니다.

사실 역자 입장 에서는 적절한 어휘 선정과, 국내 개발자의 시선에 맞게 레벨을 조정하기 위해 각주를 다는등 여러가지 노력이 필요합니다. 

또한 책이 많이 팔릴지도 의문이고, 이미 읽을만한 분은 다 읽었다고 생각이 들고, 나의 안티를 양성하지 않을까 고민이 됩니다.

실례로, 몇몇 출판사를 통해 “명서를 왜 이렇게 번역했느냐?”라며 여러가지 공격을 당한 사례들을 종종 들었기에 쉽게 움직이지 못하는 것도 사실입니다.

이러한 상황에서도 DDD가 이 세상에 나오게 해주신 이 대엽님과 여러  고생해 주신 분들에게 감사를 드립니다.

다시 본론으로 돌아와 DDD는 고객과 개발자/아키텍트 간에 대화를 나눌수 있는 좋은 도구입니다. 

 패턴 계의 철학을 생각해 보면, 모든 상황에 만능인 솔루션은 없다. 단지 상황에 맞는 해결책이 있다는 것을 생각해 볼 필요가 있습니다. 그러기에 해당 Context들이 대부분 도메인과 밀접한 연관이 있고, DDD의 초안이 PLoP 에서 첫 데뷔를 했기 때문에 역시 그 본류는 패턴의 철학과 맞 닿아 있는 방법입니다.

그럼 DDD를 프로젝트에 적용하기 이전에, 고려해야 할 것들 이야기 해보고자 합니다.  어떠헌 프로세스, 툴들에게도 동일하게 적용된느 철학입니다.  맹목적인 추종보다 결국 상황에 맞는 솔루션이라는 것을 기억해 주셔야 됩니다.

프로젝트의 범위나 개발자 스킬, 비용 문제..

2년전 Rebecca님이 정말 현실적인 아키텍트라고 생각이 든 발표가 있었습니다.

Domain 지향적인 설계 (줄여서 DDD)가 구축만 되면 재사용이 되기 쉽고 관리 비용도 낮아진다는 겁니다. 정말 Domain Logic이 복잡하고 재사용이요구될때 진가를 발휘하는게 Domain Model 인거 같습니다.

하지만 Domain Logic 자체가 복잡하지 않않는데 Domain Model을 사용한다는 거나, 기존의 Database, Transaction Script에 익숙한 DBA나 개발자들에게 Domain Model을 구축하게 만든다는 것은 정말 일종의 새로운 시도가 될수 있습니다.  그러니 주의깊게 사용해야  된다는 것이지요.

익숙하지 않는 툴과 프로세스는 좋은 지휘자가 없으면 정말 프로젝트가 산으로 갈수 있기 때문이지요. 이미 금융, 보험등과 같이 그쪽 도메인에 익숙한 분들도 계속되는 차세대에 허덕이고 있는 것이 현실입니다.

예측하지 못하는 금융, 보험 상품들의 탄생, FTA같은 변화들로 인해 결국 계속 바뀔수 밖에 없지만요..  결국 미래의 변화를 예측하지 못하는 본질적인 문제이지요. 

변화를 수렴할수 있는 구조를 만든다는 것은 정말 아키텍트의 크나큰 과제인거 같습니다.

DDD와 프레임워크간의 시각 차이 – Target User를 정확히 고려해라

정말 인기있는 프레임워크를 만드는게 목표인데, Domain 특화된 용어들을 잔뜩 적어 놓으면 그 분야의 전문가가 아닌 사람은 접근할 수 없는 성역을 만들게 된 것입니다.

사실 많은 프레임워크 설계자가 가지는 잘못된 생각입니다.  내가 그분야의 전문가이니 다들 이렇게 하면 알겠지…
.NET 프레임워크의 설계자인 Krzysztof Cwalina 의 실패 경험을 통해 나온 정말 값진 격언입니다.

여러분을 좋아하는 사용자들을 위해 설계하는 것은 쉽지만, 여러분을 좋아하지 않는 누군가를 위해 설계한다는 것은 매우 어렵다. 

도메인 전문가들(domain experts)이 설계한 매우 많은 Framework(API) 들이 있지만, 솔직히 얘기해서 그 Framework(API)들은 도메인 전문가에게만 좋다. 

대부분의 개발자들은 도메인의 전문가가 될 것도 아니며, 현재 어플리케이션(modern applications)에 적용되는 모든 기술의 전문가가 되려고 하는 것도 아니다.

프레임워크는 많은 사용자가 쓰기 위해 만든 것인데,  도메인 특화된 용어를 도배를 해버리면 굉장한 학습곡선을 요구하죠.

대안으로 일반적인 사용자를 위한 Low Level API 부터 고급 사용자를 위한 High Level API를 Wrapper Facade로 제공하는 경우도 있지만 구축 비용과 유지보수 비용도 상당히 상승하게 됩니다.

즉 무엇을 얻으면 무엇을 내줘야하는 Trade-Off의 현실과 직면하게 됩니다.

맺으며..

결국 설계란  다양한 이해당사자와  그들간의 정치, 시간, 비용들 간에 얼마나 적절한 균형을 맞추느냐에 있다는 것을 요즘 많이 깨닫고 있습니다.

맹목적인 추종보다는 상황에 맞는 해결책을 그리고 그 해결책을 관철보다는 이해당사자의 상황에 맞게 다듬는 것이 필요한데..

전 아직 갈길이 먼가 봅니다. ..

권한은 없고 책임만 가득한  IT의 현실에  묵묵히 일하고 있는 선배님, 후배님에게 격려를 표하며 저의 부족한 생각을 적어 보았습니다.