[도메인 주도 설계 첫걸음] Part 3. 도메인 주도 설계 적용 실무

본문은 도메인 주도 설계 첫걸음을 읽고 간단하게 정리한 글입니다. 필요에 따라 생략/수정된 부분이 있을 수 있으며, 내용이 추후 변경될 수 있습니다.

 

10장) 휴리스틱 설계

바운디드 컨텍스트

작은 바운디드 컨텍스트를 만드려는 목적으로 기능을 줄이는 방향으로 모델링하는 것보다는 그 반대로 하는 것이 낫다. 즉, 모델의 기능이 포함하는 크기 그대로 바운디드 컨텍스트를 다루는 것이 낫다.

• 바운디드 컨텍스트를 너무 작게 설정하여 그 경계를 리팩토링하는 것은 비용이 많이 들고, 대부분의 경우 기술 부채로 남게 된다 (물리적 경계)
• 반면 넓은 바운디드 컨텍스트의 경계 또는 여러 하위 도메인에 걸친 경계는 보다 안전하다 (논리적 경계)
• 따라서 초기에 바운디드 컨텍스트를 설계할 때는 경계를 넓게 설정하고, 추후 도메인이 쌓이게 되면 필요에 따라 작은 여러 경계로 나누어 가는 것이 좋다

 

비즈니스 로직 구현 패턴

비즈니스 로직을 모델링하는 방법을 선택하는 휴리스틱은 다음과 같다. (아래부터 따라간다)

• 하위 도메인이 금전 또는 통화의 트랜잭션을 추적하거나, 일관된 감사 로그를 제공하거나, 또는 비즈니스에서 하위 도메인의 동작에 대한 심층적인 분석을 요청하는가? -> 이벤트 소싱 도메인 모델 적용
• 하위 도메인의 비즈니스 로직이 복잡한가? -> 도메인 모델 적용
• 하위 도메인이 복잡한 자료구조를 포함하는가? -> 액티브 레코드 패턴 적용
• 위 질문에 모두 해당하지 않는다면 트랜잭션 스크립트를 적용한다

 

아키텍처 패턴

• 이벤트 소싱 도메인 모델 & 여러 영속 모델이 있는 경우 -> CQRS
• 도메인 모델 -> 포트와 어댑터
• 액티브 레코드 -> 계층형 아키텍처 (3계층)
• 트랜잭션 스크립트 -> 계층형 아키텍처 (4)

 

테스트 전략

피라미드형 테스트

• 단위 테스트가 가장 많고, 통합 테스트는 별로 없으며, E2E 테스트는 거의 없는 테스트 전략
• 애그리게이트와 밸류 오브젝트 도메인 모델 패턴에 적합
  
  • 비즈니스 로직을 테스트하기에 단위 테스트가 용이하다

다이아몬드형 테스트

• 통합 테스트에 가장 집중하는 테스트 전략
• 액티브 레코드 패턴에 적합
  • 액티브 레코드 패턴의 경우 비즈니스 로직이 서비스 계층과 비즈니스 계층에 흩어지므로 두 계층의 연동에 중점을 둔다면 통합 테스트가 용이하다

역전된 파라미드형 테스트

• E2E 테스트에 가장 집중하는 테스트 전략
• 트랜잭션 스크립트에 적합
  • 비즈니스 로직이 간단하고 계층의 수가 적으므로 시스템의 엔드-투-엔드 흐름을 검증하는 데 효과적이다

 
 

11장) 진화하는 설계 의사결정

도메인 변경

• 비즈니스 도메인이 발전함에 따라 하위 도메인에  대한 변경사항을 식별하고 시스템 설계에서 조치를 취해야 한다
• 과거의 설계 의사결정이 비즈니스 도메인과 하위 도메인의 현재 상태에 부합하는지 확인하라

조직 변화

• 조직 구조의 변화에 따라 팀 간의 의사소통과 협력, 바운디드 컨텍스트를 통합하는 방식에 영향을 줄 수 있다

도메인 지식

• 시간이 지남에 따라 더 많은 도메인 지식이 발견되면 그것을 전략적, 전술적 설계 의사결정을 발전시키는 데 활용해야 한다

소프트웨어 성장

• 하위 도메인이 확장되면 더 세분화된 하위 도메인 경계를 식별하려고 노력하라
• '여러 방면에 다재다능한' 바운디드 컨텍스트가 되는 것을 허용하는 대신 바운디드 컨텍스트에 포함된 모델이 특정 문제를 해결하는 데 중점을 두고 있는지 확인하라
• 애그리게이트의 경계를 가능한 한 작게 유지하라

 

13장) 실무에서의 도메인 주도 설계

비즈니스 도메인 분석

• 회사의 목표와 전략을 파악하라
• 조직 구조와 기존 소프트웨어 설계 의사결정을 사용하여 조직의 하위 도메인과 해당 유형을 식별하라

현대화

• 이러한 지식들을 바탕으로 현대화 전략을 계획하고, 관련 컴포넌트를 리팩터링하거나 교체함으로써 레거시 코드를 현대화라
• 이때, 반드시 점진적으로 수행해야 한다

실용적인 도메인 주도 설계

• DDD가 제공하는 모든 도구를 적용할 필요는 없다
• 도메인 주도 설계는 비즈니스 도메인이 소프트웨어 설계 의사결정을 주도하게 하는 것이다

도메인 주도 설계 확산

• 항상 DDD가 조직에서 널리 채택되지 않은 경우에도 도메인 주도 설계 도구를 사용할 수 있음을 명심하라
• 올바른 도구를 사용하고 동료와 논의할 때 항상 각 패턴 뒤에 있는 논리와 원칙을 사용하라