[Domain Driven Design] 휴리스틱 설계

다양한 소프트웨어 설계 의사결정, 즉 도메인 주도 설계를 돕는 분석도구를 사용하는 휴리스틱에 대해 알아 보고자 한다.

1. 휴리스틱

휴리스틱을 사용하는 것은 수 많은 단서에 내재된 노이즈를 무시하면서도 가장 중요한 단서에서 느껴지는 ‘압도하는 힘’에 집중하여 효과적으로 문제를 해결하는 접근법이다.

2. Bounded Context

바운디드 컨텍스트의 최적의 크기에 대한 질문은 MSA와 Bounded Context를 빈번히 다루는 환경에서는 특히 중요하다.

• 한 서비스를 경계를 정의하는 데 있어 크기로 경계를 구분하는 것은 가장 도움이 되지 않는다.
  → 모델의 어떤 기능이 포함하는 크기 그대로 바운디드 컨텍스트를 다루는 것이 좋다.
  
• 변동성이 큰 핵심 하위 도메인에 있어서 넓은 바운디드 컨텍스트 경계를 통해 안전하게 한다.
  → 논리적 경계 리팩토링 비용 < 물리적 경계 리팩토링 비용
  
• 차후에 도메인 지식이 쌓이게 되면 필요에 따라 넓은 경계를 좀 더 작은 여러 경계로 쪼갠다.

3. 비즈니스 로직 구현 패턴

비즈니스 로직을 구현하는데 크게 4가지 패턴이 있다고 한다. 트랜잭션 스크립트, 액티브 레코드, 도메인 모델, 이벤트 소싱 도메인 모델

4. 아키텍처 패턴

5. 테스트 전략

end-to-end, 통합, 단위 테스트의 강조에 따라 전략이 나뉜다.

• 피라미드형 테스트
  • 단위 테스트를 강조하고 통합 테스트는 별로 없으며, end-to-end 테스트는 더더욱 없다.
  • Aggregate와 VO 도메인 모델 패턴을 모두 잘 지원한다. → 비즈니스 로직을 테스트하는 완벽한 단위
  • end-to-end < 통합 < 단위
• 다이아몬드형 테스트
  • 통합 테스트에 집중한다.
  • 액티브 레코드 패턴이 사용되면 시스템의 비즈니스 로직은 서비스 계층과 비즈니스 로직 계층에 흩어지므로 두 계층의 연동에 중점을 둘때 유용하다.
  • end-to-end < 통합 > 단위
• 역전된 피라미드형 테스트
  • end-to-end 테스트에 가장 많이 집중 → 처음부터 끝까지 App의 워크플로우를 검증하는 것이다.
  • 트랜잭션 스크립트 패턴에 적합
  • 로직이 간단하고 계층의 수가 적으므로 검증하는데 효과적이다.
  • end-to-end > 통합 > 단위

6. 전술적 설계 의사결정 트리