바운디드 컨텍스트의 경계, 비즈니스 로직을 모델링, 아키텍처 패턴 결정, 테스트 전략 결정하는 데에 있어 휴리스틱을 활용할 수 있다.
항상 정확한 것은 아니기 때문에 가이드 규칙으로서 사용하고, 과거의 의사결정이 유효한지 검증하는 것이 중요하다.
휴리스틱은 모든 상황에 맞는 검증된 규칙이 아닌 충분한 경험에 기반한 규칙이다.
즉, 가장 중요한 단서에서 느껴지는 **'압도하는 힘'**에 집중하여 효과적으로 문제를 해결하는 접근법이다.
한 서비스의 경계를 정의하는 데 있어 식별을 용이하게 해주는 유용한 휴리스틱은 매우 많다.
그러나 그중 크기로 경계를 구분하는 것은 가장 도움이 되지 않는다.
모델의 어떤 기능이 포함하는 크기 그대로 바운디드 컨텍스트를 다루는 것이 효과적이다.
여러 바운디드 컨텍스트에 영향을 미치는 변경이 일어날 때 단일 바운디드 컨텍스트 내에 있지 않다면 이는 컨텍스트의 경계가 효과적이지 않다는 신호다.
핵심 하위 도메인과 같이 비즈니스 도메인이 잘 알려져 있지 않거나 요구사항이 빈번하게 바뀔 때 바운디드 컨텍스트의 경계를 무효화하는 변경이 발생한다.
논리적 경계를 리팩터링하는 것은 물리적 경계에 비해 적은 비용이 들기 때문에 바운디드 컨텍스트를 설계할 때 경계를 넓게 해서 시작하고 도메인 지식이 쌓이면 좀 더 작은 여러 경계로 쪼갠다.
일반 하위 도메인과 지원 하위 도메인은 변동싱이 훨씬 적으므로 이 같은 휴리스틱은 주로 핵심 하위 도메인을 포함하는 바운디드 컨텍스트에 적용된다.
핵심 하위 도메인과 빈번하게 상호작용하는 다른 하위 도메인을 포함하면 예측하지 못한 변경으로부터 스스로를 보호할 수 있다.
비즈니스 로직을 모델링하는 방법은 네 가지 방법이 있다.
- 트랜잭션 스크립트 패턴
- 액티브 레코드 패턴
- 도메인 모델 패턴
- 이벤트 소싱 도메인 모델 패턴
트랜잭션 스크립트와 액티브 레코드 패턴은 간단한 비즈니스 로직을 포함하는 하위 도메인에 적합하다.
두 패턴은 사용되는 자료구조의 복잡성에 따라 다르다.
도메인 모델과 이벤트 소싱 도메인 모델 패턴은 복잡한 비즈니스 로직을 가진 핵심 하위 도메인에 적합하다.
비즈니스 로직의 구현 패턴을 선택하기 위한 효과적인 휴리스틱은 다음과 같은 질문을 통해 알 수 있다.
- 하위 도메인이 금전 또는 통화의 트랜잭션을 추적하거나, 일관된 감사 로그를 제공하거나, 또는 비즈니스에서 하위 도메인의 동작에 대한 심층적인 분석을 요청하는가? 그렇다면 이벤트 소싱 도메인 모델을 적용한다. 그렇지 않다면
- 하위 도메인의 비즈니스 로직이 복잡한가? 그렇다면 도메인 모델을 구현한다. 그렇지 않다면
- 하위 도메인이 복잡한 자료구조를 포함하는가? 그렇다면 액티브 레코드 패턴을 사용한다. 그렇지 않다면
- 트랜잭션 스크립트를 구현한다.
하위 도메인의 복잡성과 유형은 강한 관계가 있으므로 다음과 같이 도메인 주도 의사결정 트리로 나타낼 수 있다.
비즈니스 로직의 복잡성을 정의하는 데도 휴리스틱을 사용할 수 있다.
일반적으로 복잡한 비즈니스 로직은 복잡한 비즈니스 규칙, 불변성, 알고리즘을 포함한다.
간단한 접근 방법은 주로 입력을 검증한다.
또한 유비쿼터스 언어 자체의 복잡성을 평가하는 휴리스틱도 있다.
비즈니스 로직과 그 자료구조의 복잡성에 따라 비즈니스 로직의 구현 패턴을 결정하는 것은 하위 도메인과 비즈니스 도메인에 대한 추측을 다시 되돌아보는 좋은 기회가 된다.
세 가지 아키텍처 패턴은 다음과 같다.
- 계층형 아키텍처 패턴
- 포트와 어댑터 아키텍처 패턴
- CQRS
아키텍처 패턴이 의도한 비즈니스 로직 구현 패턴을 알면 쉽게 아키텍처 패턴을 선정할 수 있다.
- 이벤트 소싱 도메인 모델 패턴은 CQRS가 필요하다. 그렇지 않으면 시스템은 데이터 질의 옵션이 극심하게 제한되어 자신의 ID만으로 단일 인스턴스를 가져와야 한다.
- 도메인 모델 패턴은 포트와 어댑터 아키텍처가 필요하다. 계층형 아키텍처에서는 영속성에 대한 고려 없이 애그리거트와 밸류 오브젝트를 만들기가 어렵다.
- 액티브 레코드 패턴은 애플리케이션(서비스) 계층을 추가한 계층형 아키텍처와 잘 어울린다. 이는 액티브 레코드를 제어하는 로직을 위한 것이다.
- 트랜잭션 스크립트 패턴은 세 개의 계층만으로 이어진 최소한의 계층형 아키텍처를 적용하여 구현할 수 있다.
위의 휴리스틱에서 CQRS는 이벤트 소싱 도메인 모델 패턴 뿐만 아니라 하위 도메인이 여러 영속 모델에 있는 데이터를 표현할 필요가 있는 경우에도 도움이 된다.
위의 휴리스틱 기반으로 아키텍처 패턴을 선택하는 의사결정 트리는 다음과 같다.
비즈니스 구현 패턴과 아키텍처 패턴의 모든 지식은 코드베이스의 테스트 전략을 선택할 때 휴리스틱으로 활용할 수 있다.
고전적인 피라미드형 테스트 전략에서는 단위 테스트를 강조하고 애그리거트와 밸류 오브젝트 도메인 모델 패턴을 모두 지원한다.
두 도메인 모델 패턴은 사실상 비즈니스 로직을 테스트하는 완벽한 단위다.
다이아몬드형 테스트에서 가장 집중하는 유형은 통합 테스트다.
액티브 레코드 패턴이 사용되면 시스템의 비즈니스 로직은 서비스 계층과 비즈니스 로직 계층에 흩어지므로 두 계층의 연동에 중점을 둔다면 효과적으로 테스트할 수 있다.
역전된 피라미드형 테스트 전략은 엔드-투-엔드 테스트에 가장 많이 집중한다.
처음부터 끝까지 애플리케이션의 워크플로를 검증해 트랜잭션 스크립트 패턴을 구현한 코드베이스에 잘 어울린다.
테스트 전략을 결정하는 의사결정 트리는 다음과 같다.
비즈니스 로직 패턴, 아키텍처 패턴, 테스트 전략에 관한 휴리스틱은 다음과 같이 하나의 전술적 설계 의사결정 트리로 합쳐서 요약할 수 있다.
하위 도메인의 유형을 식별하고 의사결정 트리를 참조하는 것은 필수적인 서계 의사결정을 위한 시작점이다.
모든 규칙에는 예외가 있듯이, 휴리스틱을 반복하는 것이 중요하지만 항상 맞는 것은 아니다.
특정 상황에 따라 효과적인 접근 방법은 달라지므로 의사결정 트리는 중요한 의사결정 방식을 대체하는 것이 아닌 가이드 규칙으로 사용해야 한다.
휴리스틱 기반 의사결정 프레임워크와 연관 지어 기술적 의사결정을 내리는 데 비즈니스 도메인 지식과 그 하위 도메인을 적용하는 방법을 배웠다.
- 바운디드 컨텍스트 경계 선택하기
- 애플리케이션의 비즈니스 로직 모델링하기
- 바운디드 컨텍스트의 내부 구성요소를 조율하는 아키텍처 패턴 결정하기
- 비즈니스 도메인에 따른 테스트 종류 결정하기
설계 의사결정을 내리는 것도 중요하지만, 시간이 지나면서 과거의 의사결정이 유효한지 검증하는 것이 더 중요하다.
그동안 전략적 설계와 전술적 설계의 이론으로서 배운 것들을 어떻게 직접 적용할 수 있는지 쉽게 알려주었다.
휴리스틱을 이용한 의사 결정 트리를 통해 바운디드 컨텍스트의 경계, 비즈니스 로직을 모델링, 아키텍처 패턴 결정, 테스트 전략 결정하는 방법을 알 수 있었다.
의사 결정 트리는 단순한 가이드 규칙으로 사용하고, 설계 의사결정을 내리는 것보다 과거의 의사결정이 유효한지 검증하는 것이 더 중요하다는 것을 알게되었다.