TDD와 관계

DDD

• 비즈니스 도메인을 깊이 이해하여 소프트웨어 시스템을 설계하는 데 중점을 두는 아키텍쳐 접근 방식
• 도메인 전문가와 소프트웨어 개발자 간 협업을 강조
• 복잡한 비즈니스 요구 사항에 대한 공동의 이해를 창출
• 비즈니스 도메인의 개념, 언어 및 프로세스를 기반으로 소프트웨어 시스템을 모델링하는 것을 옹호

TDD

• 프로덕션 코드 작성 전 자동화된 테스트를 작성하는 것을 지지하는 소프트웨어 개발 관행
• Red-Green-Refactoring 주기를 따르며, 처음에 원하는 기능을 정의하기 위해서 실패한 테스트 케이스를 작성
• 그 다음 테스트를 통과할 수 있을 만큼만 구현
• 마지막으로 코드, 테스트를 리팩토링해서 모든 테스트를 통과하면서 품질을 개선

시너지

1. 공유된 이해
   • 둘 다 이해 관계자, 도메인 전문가, 개발자 간의 협업과 커뮤니케이션을 장려
   • TDD는 개발자가 도메인 전문가가 이해할 수 있는 언어로 테스트를 작성하도록 정려
2. 점진적 개발
   • 개발자가 관리하기 쉬운 작은 단위로 테스트와 코드를 작성하는 점진적 개발을 장려
   • 이러한 흐름은 반복 개발과 도메인 전문가의 지속적인 피드백을 강조하는 DDD와 궤를 같이함
3. 문서로서의 테스트
   • TDD에서 테스트는 실행 가능한 문서의 한 형태
   • 테스트는 시스템의 예상 동작과 기능을 설명
   • 구현 검증과 코드베이스가 도메인 모델 및 요구 사항과 일치하도록 보장하는 살아있는 문서
4. 품질 보증
   • TDD는 초기 회귀와 버그를 잡아낼 수 있는 안전망을 제공
   • 이는 비즈니스 목표에 부합하는 고품질 소프트웨어를 제공한다는 DDD의 목표와 일치
5. 리팩토링 및 유연성 유지
   • 둘 다 설계와 유지보수성을 개선하기 위해서 리팩토링을 권장
   • TDD의 리팩토링 단계를 통해 건설적인 방향으로 코드베이스를 발전시킬 수 있다. DDD가 도메인에 대한 진화하는 이해를 바탕으로 리팩토링하고 개선하기 위한 접근을 하는 것과 뜻을 같이한다.