DDD와 TDD

..

 

제대로 DDD를 실행한다고 해서 수많은 절차와 이를 지원할 복잡한 문서 산출물 때문에 프로세스가 무거워진다는 의미는 아니다.
DDD는 그런 것이 아니다.

DDD는 스크럼 같은 팀이 사용하길 원하는 어떤 애자일 프로젝트 프레임워크와도 잘 맞는다.
이 설계 원칙은 오히려 테스트 우선 방식(TDD test first : Test -> Code -> Refact) 에 따라 실제 소프트웨어 모델을 빠르 게 정제해나가는 방식에 더 가깝다. 여러분이 엔터티나 값 객체와 같은 새로운 도메인 객체의 개발이 필요한 상황이라면, 테스트 우선의 접근법은 다음과 같이 작동한다.

1. 도메인 모델의 클라이언트가 새로운 도메인 객체를 사용하는 방법을 보여주는 테스트를 작성하라.
2. 새로운 도메인 객체를 만들 때는 테스트를 컴파일할 수 있을 정도로 충분한 코드를 함께 작성하라.
3. 테스트가 클라이언트가 도메인 객체를 사용하는 방법을 제대로 나타내고, 도메인 객체가 올바른 행동적 메소드 시그니처를 갖게 될 때까지 리팩토링하라.
4. 테스트가 성공할 때까지 각 도메인 객체의 행동을 구현하고, 부적절한 코드의 중복이 없어질 때까지 도메인 객체를 리팩토링하라.
5. 유비쿼터스 언어의 현재 의미에 맞는 도메인 객체를 사용해 테스트하는지 확인할 수 있도록, 도메인 전문가를 포함한 팀원에게 코드를 시연하라.

여러분은 아마도 이미 여러분이 사용하고 있는 테스트 우선 접근법과 다를 바가 없다고 결론을 내릴지도 모른다. 
글쎄, 아마 작은 차이점이 있을지도 모르지만 기본적으론 완전히 동일하다.
모델이 완전무결하다는 절대적 확신을 위해 이런 테스트 단계를 거치는 것이 아니다.
이를 위해선 좀 더 뒤에서 테스트를 추가할 것이다.
우선 지금은 클라이언트가 모델을 사용하는 방법에 초점을 맞추며,
이런 테스트는 모델의 설계를 주도하게 된다.
좋은 소식은 이것이야말로 진정으로 애자일한 접근법 이라는 점이다.

DDD는 경량 개발을 추구하지, 단계가 많고 무겁고 선행투자가 필요한 설계는 아니다.
이런 관점에서 DDD는 일반적인 애자일 개발과 정말 다르지 않다.
위의 단계가 애자일하게 느껴지지 않더라도, DDD를 애자일 방식에 맞춰 사용할 수 있다는 점만큼은 분명하다.

 - Implementing Domain-Driven Design 도메인 주도 설계 구현, 반 버논 p92

 

..