Ch10. 휴리스틱 설계
이번 장은 1부와 2부의 가교 역할을 한다.
우선, 휴리스틱의 정의가 무엇인지부터 알아보자.
[휴리스틱]
휴리스틱은 모든 상황에 맞게 보장되고 수학적으로 검증된 규칙이 아니다.
오히러 완벽한 것을 보장하지 않지만 당면한 목적에 충분할 만큼의 경험에 기반한 규칙이다.
즉, 휴리스틱은 가장 중요한 단서에서 느껴지는 것에 집중하여 효과적으로 문제를 해결하는 접근법이다.
[바운디드 컨텍스트]
바운디드 컨텍스트의 최적의 크기는 무엇일까?
여러 바운디드 컨텍스트에 영향을 미치는 소프트웨어의 변경은 비싸고 수많은 조율이 필요하다.
바운디드 컨텍스트의 경계를 무효화하는 변경은 일반적으로 비즈니스 도메인이 잘 알려져 있지 않거나 비즈니스 요구사항이 빈번하게 바뀔 때 발생한다.
넓은 바운디드 컨텍스트의 경계 또는 여러 하위 도메인에 걸친 경계는 그 경계 또는 하위 도메인을 포함하는 모델이 잘못돼도 안전하게 해준다.
그러므로 처음 설계할 때 경계를 넓게 설정하자.
[비즈니스 로직 구현 패턴]
이전 장에서 우리는 비즈니스 로직을 모델링하는 네 가지 방법을 배웠다.
- 트랜잭션 스크립트
- 액티브 레코드
- 도메인 모델
- 이벤트 소싱 도메인 모델
트랜잭션 스크립트와 액티브 레코드 패턴은 간단한 비즈니스 로직을 포함하는 하위 도메인의 경우 적합하다.
도메인 모델과 이벤트 소싱 도메인 모델은 복잡한 비즈니스 로직을 가진 핵심 하위 도메인에 적합하다.
이 모든 것을 고려한다면, 적절한 구현 패턴을 선택하기 위한 효과적인 휴리스틱은 다음과 같이 질문해보는 것이다.
- 하위 도메인이 금전 또는 통화의 트랜잭션을 추적하거나, 일관된 감사 로그를 제공하거나, 심층적인 분석을 요청하는가? 그렇다면 이벤트 소싱 도메인 모델을 적용한다. 그렇지 않다면
- 하위 도메인의 비즈니스 로직이 복잡한가? 그렇다면 도메인 모델을 구현한다. 그렇지 않다면
- 하위 도메인이 복잡한 자료구조를 포함하는가? 그렇다면 액티브 레코드 패턴을 사용한다. 그렇지 않다면
- 그것이 아니라면 트랜잭션 스크립트를 구현한다.
또 다른 휴리스틱으로는 일반적으로 복잡한 비즈니스 로직은 복잡한 비즈니스 규칙, 불변성, 알고리즘을 포함한다.
또한 유비쿼터스 언어 자체의 복잡성을 평가하는 다른 휴리스틱도 있다.
예를 들어 언어에서 주로 CRUD 동작을 표현하는가? 아니면 좀 더 복잡한 비즈니스 프로세스와 규칙을 설명하는가?
[아키텍처 패턴]
아키텍처 패턴이 의도한 비즈니스 로직 구현 패턴을 알면 쉽게 선정할 수 있다.
- 이벤트 소싱 도메인 모델은 CQRS가 필요하다. 그렇지 않으면 시스템은 데이터 질의 옵션이 극심하게 제한되어 자신의 ID만으로 단일 인스턴스를 가져와야 한다.
- 도메인 모델은 포트와 어댑터 아키텍처가 필요하다. 계층형 아키텍처에서는 영속성에 대한 고려 없이 애그리게이트와 밸류 오브젝트를 만들기가 어렵다.
- 액티브 레코드 패턴은 애플리케이션(서비스) 계층을 추가한 계층형 아키텍처와 잘 어울린다. 이는 액티브 레코드를 제어하는 로직을 위한 것이다.
- 트랜잭션 스크립트 패턴은 세 개의 계층만으로 이어진 최소한의 계층형 아키텍처를 적용하여 구현할 수 있다.
[테스트 전략]
그림 10-5에 세 가지 테스트 전략을 표현했다.
피라미드형 테스트
고전적인 피라미드형 테스트 전략은 단위 테스트를 강조하고, 통합 테스트는 별로 없으며, 앤드-투-앤드 테스트는 더더욱 없다.
도메인 모델 패턴을 잘 지원하며, 비즈니스 로직을 테스트하기 완벽한 단위다.
다이아몬드형 테스트
다이아몬드형 테스트는 통합 테스트에 가장 집중하는 유형이다.
액티브 레코드 패턴이 사용되면 비즈니스 로직이 서비스 계층과 비즈니스 로직 계층으로 흩어지므로 두 계층의 연동에 중점을 둔다면 다이아몬드형 테스트가 효과적이다.
역전된 피라미드형 테스트
역적된 피라미드형 테스트는 엔드-투-엔드 테스트에 가장 많이 집중한다.
이 접근 방법은 트랜잭션 스크립트 패턴을 구현한 코드베이스에 가장 잘 어울린다.
[전술적 설계 의사결정 트리]
그림 10-7 처럼 하나의 전술적 설계 의사결정 트리로 합쳐서 요약할 수도 있다.
이처럼 하위 도메인의 유형을 식별하고 의사결정 트리를 참조하는 것은 필수적인 설계 의사결정을 위한 시작점이다.
즉, 고정된 규칙이 아닌 휴리스틱을 반복하는 것이 중요하다.
결국 특정 상황에 따라 효과적인 접근 방법은 달라진다.
그러므로 그림 10-7에 표현한 의사결정 트리는 가이드 규칙정도로만 사용하자.
[결론]
설계 의사결정을 내리는 것도 중요하지만, 더 중요한 것은 시간이 지나면서 과거의 의사결정이 여전히 유효한지를 검증하는 것이다.
Ch11. 진화하는 설계 의사결정
빠르게 변화하는 현대 사회에서 기업은 정신을 바짝 차려야 한다.
이번 장에서는 소프트웨어 프로젝트 환경의 변화가 소프트웨어 설계 의사결정에 어떻게 영향을 미칠 수 있는지 살펴보자.
[도메인 변경]
2장에서 우리는 세 가지 유형의 비즈니스 하위 도메인을 알아보고 서로 어떻게 다른지 배웠다.
핵심
- 기업이 경쟁 우위를 확보하기 위해 경쟁자와 도르게 수행하는 활동
지원
- 회사가 경쟁자와 다르게 하고 있지만, 경쟁 우위를 제공하지 않는 활동
일반
- 모든 회사가 같은 방식으로 하는 일
이전 장에서 실행 중인 하위 도메인 유형이 전략적 및 전술적 설계 의사결정에 영향을 미치는 것을 봤다.
- 바운디드 컨텍스트의 경계를 설계하는 방법
- 컨텍스트 간의 연동을 조율하는 방법
- 복잡한 비즈니스 로직을 다루기 위해 사용할 디자인 패턴
비즈니스 도메인의 요구사항에 따라 구동되는 소프트웨어를 설계하려면 비즈니스 하위 도메인과 해당 유형을 식별하는 것이 중요하다.
그러나 그것이 전부가 아니다.
하위 도메인의 진화에 주의를 기울이는 것도 마찬가지로 중요하다.
핵심에서 일반으로
BuyIT라는 온라인 소매 회사가 자체 주문 배송 솔루션을 구현했다고 상상해보자.
배송 경로를 최적화하는 혁신적인 알고리즘을 개발하여 경쟁사보다 낮은 배송료를 청구할 수 있다.
어느 날 또 다른 회사인 DeliverIT가 배송 업계를 혼란에 빠뜨린다.
‘외판원 문제’를 해결했으며, 더 최적화 경로 서비스를 제공한다고 주장한다.
BuyIT 관점에서 DeliverIT의 솔루션이 상용 제품으로 제공되면 핵심 하위 도메인이 일반 하위 도메인으로 바뀐다.
일반에서 핵심으로
BuyIT는 재고를 관리하기 위해 상용 솔루션을 사용해 왔다.
그러나 사용하던 솔루션의 재고 예측이 계속해서 잘못되는 것을 발견했다.
BuyIT는 재고 관리를 위한 사내 시스템 셜계 및 구축에 투자하기로 전략적 결정을 내린다.
이런 경우 일반 하위 도메인이 핵심 하위 도메인으로 바뀐다.
아마존이 이 사례의 좋은 예제다.
지원에서 일반으로
BuyIT의 마케팅 부서는 협력하는 공급업체와 계약을 관리하기 위한 시스템을 구현했다.
이 시스템은 특별하거나 복잡하지 않으며, 데이터를 입력하기 위한 일부 CRUD 인터페이스만 필요했다.
즉, 전형적인 지원 하위 도메인이다.
그러나 몇 년 후 계약 관리 솔루션이 오픈소스로 나왔다.
이 오픈소스는 기존 솔루션의 기능에 OCR과 전문 검색과 같은 고급 기능까지 제공한다.
따라서 회사는 사내 솔루션을 버리고 오픈 소스 솔루션으로 연동하기로 결정했다.
이는 지원 하위 도메인이 일반 하위 도메인으로 바뀐다.
지금까지 사례를 보며 다음 그림을 참고해보자.
[전술적 설계 문제]
하위 도메인의 유형 변경을 나타내는 주요 지표는 기존의 기술적 설계가 현재 비즈니스 요구를 지원할 수 없는 경우다.
지원 하위 도메인이 핵심 하위 도메인이 되는 예를 보자.
지원 하위 도메인은 비즈니스 로직을 모델링하기 위해 비교적 단순한 트랜잭션 스크립트 또는 액티브 레코드 패턴으로 구현될 것이다.
하지만 이러한 패턴은 복잡한 규칙과 불변성을 가진 비즈니스 로직에는 적합하지 않다.
트랜잭션 스크립트에서 액티브 레코드로
기본적으로 트랜잭션 스크립트와 액티브 레코드 패턴은 모두 절차지향 스크립트를 사용하여 비즈니스 로직을 구현한다.
그러나 다 자료구조는 모델링하는 방식에 차이가 있다.
결과적으로 트랜잭션 스크립트에서 데이터 작업이 어려워지면 그것을 액티브레코드 패턴으로 리팩토링 하자.
액티브 레코드에서 도메인 모델로
액티브 레코드를 조작하는 비즈니스 로직이 점점 더 복잡해지고 불일치 및 중복 사례가 많아진다면 도메인 모델 패턴으로 리팩토링 하자.
리팩토링 과정을 보면
- 밸류 오브잭트를 먼저 식별해봐라.
- 자료구조를 분석하고 트랜잭션 경계를 찾아라.
- 마지막으로 각 애그리게이트에 대해 루트 또는 퍼블릭 인터페이스의 앤드포인트를 식별하라.
[조직 변화]
시스템 설계에 영향을 줄 수 있는 또 다른 변화의 유형은 조직 자체의 변화다.
그림 11-2와 같이 이러한 변화의 예시로 개발 센터의 성장을 예로 들 수 있다.
[도메인 지식]
도메인 주도 설계의 핵심 신조는 성공적인 소프트웨어 시스템을 설게하는데 도메인 지식이 반드시 필요하다는 것이다.
전략적 설계 관점에서 볼 때 도메인 지식 수준에 따라 바운디드 컨텍스트의 경계를 설게하는 것은 유용한 휴리스틱이다.
도메인 로직이 불명확하고 자주 변경되는 경우 바운디드 컨텍스트를 더 넓은 경계로 설계하는 것이 합리적이다.
새로운 도메인 지식이 발견되면 이를 활용하여 설계를 발전시키고 회복성을 높여야 한다.
[성장]
성장은 시스템이 건강하다는 신호다.
새로운 기능이 지속해서 추가된다는 것은 시스템이 성공적이라는 신호다. 반대로 성장에는 어두운 면이 따라온다.
이를 ‘커다란 진흙 덩어리’라고 한다.
“커다란 진흙 덩어리는 엉터리 구조의 거대하고 허술한 와이어 무더기와 강력 접착 테이프 범벅의 스파게티 코드 정글과도 같다. 이러한 시스템은 규제되지 않은 성장과 반복적이고 편의에 따른 수리의 명백한 징후다.”
커다란 진흙 덩어리는 규제 없는 성장을 통해 시스템을 확장한 결과다.
성장에 따른 복잡성을 다루는 기본 원칙은 우발적 복잡성, 즉 오래된 설계의 결정으로 발생하는 복잡성을 식별하고 제거하는 것이다.
하위 도메인
하위 도메인의 완벽한 경계를 찾기 위해 노력하는 대신 유용한 경계를 찾기 위해 노력해야 한다.
이를 위해 이미 식별된 하위 도메인을 다시 확인하고, 응집된 유스케이스에서 휴리스틱을 활용하여 하위 도메인을 나누는 지점을 다시 식별하는 것이 중요하다.
다양한 유형의 세분화된 하위 도메인을 식별할 수 있다면 비즈니스 도메인의 본질적인 복잡성을 관리할 수 있는 중요한 통찰력을 보여줄 수 있다.
바운디드 컨텍스트
프로젝트가 발전하고 성장함에 따라 바운디드 컨텍스트가 초점을 잃고, 다양한 문제와 관련된 로직이 늘어나는 일은 흔한 일이다.
따라서 하위 도메인과 마찬가지로 바운디드 컨텍스트의 경계를 때때로 살펴보는 것이 중요하다.
애그리게이트
경험상 애그리게이트는 가능한 한 작게 유지하고, 비즈니스 도메인에서 강력하게 일관적인 상태를 유지해야 하는 객체만 포함한다.
시스템의 비즈니스 요구사항이 증가함에 따라 애그리게이트를 작게 유지한다는 원칙을 떠올리지 않고, 이미 있는 애그리게이트에 새로운 기능을 배포하는 것이 편할 수 있다.
하지만 이는 우발적 복잡성을 유발할 수 있다.
따라서 비즈니스 기능을 전담하는 애그리게이트로 추출하면 원래 애그리게이트가 단순해질 뿐만 아니라 잠재적으로 해당 애그리게이트가 속한 바운디드 컨텍스트도 단순해진다.
[결론]
비즈니스 도메인이 발전함에 따라 하위 도메인에 대한 변경사항을 식별하고 시스템 설계에서 조치를 취해야 한다.
과거의 설계 의사결정이 유효한지 확인하고, 필요한 경우 현재 비즈니스 젼략과 요구사항에 더 맞게 설계를 발전시켜라.
마지막으로 소프트웨어 성장은 원하는 유형의 변화지만, 올바르게 관리되지 않으면 시스템 설계와 아키텍처에 치명적인 영향을 줄 수 있다.
- 그러므로 하위 도메인의 기능이 확장되면 더 나은 설계 의사결정을 내릴 수 있도록 더 세분화된 하위 도메인 경계를 식별하려고 노력하라.
- ‘여러 방면에 다재다능한’ 바운디드 컨텍스트가 되는 것을 허용하지 마라.
- 애그리게이트의 경계가 가능한 한 작은지 확인하라.
'Book Notes' 카테고리의 다른 글
| [개발서적] 도메인 주도 설계 첫걸음 3부(ch12~13) 요약 (2) (0) | 2026.01.11 |
|---|---|
| [개발서적] 도메인 주도 설계 첫걸음 2부(ch7~9) 요약 (2) (0) | 2026.01.11 |
| [개발서적] 도메인 주도 설계 첫걸음 2부(ch5~6) 요약 (1) (0) | 2026.01.11 |
| [개발서적] 도메인 주도 설계 첫걸음 1부(ch3~4) 요약 (2) (0) | 2026.01.10 |
| [개발서적] 도메인 주도 설계 첫걸음 1부(ch1~2) 요약 (1) (0) | 2026.01.10 |