도메인 주도 설계 구현
DDD를 시작하며
DDD 적용 난관
일반적인 문제점
- 유비쿼터스 언어를 만드는 데 드는 시간과 노력을 계산하는 것
- 도메인 전문가를 시작부터 참여시키고 프로젝트 내내 함께하는것
- 도메인 내의 해결책에 관한 개발자의 사고방식을 바꾸는것
DDD를 할때는 도메인 전문가의 참여가 필수이다. 많은 개발자가 DDD를 제대로 적용하기 위해 사고하는 방식을 바꿔야 한다.
데이터 중심의 사고에서 행동을 노출 시키도록 노력
도메인 모델링의 합리화
DDD의 전술적 패턴(애그리게잇, 서비스, 값 객체, 이벤트 등)을 사용해 도메인 모델을 개발한다면 더 신중한 생각과 많은 투자가 필요하다
만약 바운디드 컨텍스트가 핵심 도메인으로 만들어지고 있다면, 이는 비즈니스 성공의 측면에서 전략적으로 매우 중요하다.
많은 리팩토링과 실험이 필요하다. 만약 바운디드 컨텍스트가 복잡하고 혁신적이며 변화를 겪는 오랜 시간 동안 견뎌내야 한다면
전술적 패턴을 사용하는 방안을 진지하게 고민해보라. 높은 기술 수준의 최고 개발자가 참여한다는 가정을 전재한다.범용 서브도메인이나 고객 지원 서브도메인이 될 도메인이라며 실제로 여러분 비지니스에서 핵심 도메인이 될수도 있다.
최고 비즈니스 이니셔티브로서 바운디드 컨텍스트를 개발해가고 있다면, 비즈니스 밖에 고객이 어떻게 생각하던지 핵심 도메인이다.
전술적 패턴의 사용을 진지하게 고민하라.여러가지 이유로 써드파티 범용 서브도메인에선 얻을 수 없는 지원 서브도메인을 개발하고 있다면 전술적 패턴이 당신의 노력에 도움이 될 가능성이 있다.
만약 비즈니스 가치를 더하고, 특별한 지식을 담고 있고, 단순히 기술적 흥미가 생기는 것에 그치지 않는다면 이모델은 혁신 적인 것이다.
전술적 설계에 투자할 좋은 기회이다. 비지니스 관점에서는 단순 지원 기능이라 이 모델이 핵심 도메인이 되는 것은 아니다.
비지니스 도메인의 타입만으로 개발 접근법이 바로 선택되는 것은 아니다.
좀더 상세한 결정 기준은
- 도메인 전문가가 있고, 그들의 주변에 팀을 형성할 준비가 됐는가?
- 현재는 다소 간단한 비지니스 도메인이라도 시간이 지나면서 복잡성이 증가할것인가?
- 현재 트랜잭션 스크립트를 사용하고 있다면, 만약 컨텍스트가 복잡해졌을 때 행동적 도메인 모델로 리팩토링할 가능성은 얼마나 가시적인가?
- DDD 전술적 패턴의 사용이 써드파티가 개발했거나 사용자 정의로 만들어진 다른 바운디드 컨텍스트를 통합할때 좀더 쉽고 실용적인가
- 트랜젝션 스크립트를 사용한다면 정말 개발이 더 간단해지고 코드의 양이 줄어드나
- 전술적 투자에 필요한 부담이 크리티컬 패스와 추진 일정에 반영됐나?
- 핵심 도메인의 전술적 투자가 아키텍처적 영향이 바뀌었을 때 시스템을 보호해줄 것인가? 트랜젝션 스크립트라면 노출됀채로 둘 것이다.
- 클라이언트/고객이 좀더 영속적인 설계와 개발 접근법으로 이익을 보는가?
- 전술적 DDD를 사용해 애플리케이션/서비스를 개발하는 편이 트랜젝션 스크립트와 같은 다른 접근법을 사용할 때보다 더 어려운가?
- DDD를 가능케 도와주는 이와 함께 팀의 툴킷이 완성된 상황에서, 우리는 양심에 따라 다른 접근법의 사용을 선택할 수 있겠는가?
DDD는 무겁지 않다
DDD는 실행한다고 수만은 절차와 이를 지원할 복잡한 문서 산출물 때문에 프로세스가 무거워 지는것을 말하는것은 아니다.
오히려 TDD 같은 방식에 가깝다.