결정-0049: 컨텍스트 경계를 애그리거트 소유로 긋는다
상태
Accepted
맥락
업무 도메인을 컨텍스트로 나눌 때 판정 기준이 필요합니다. 기준이 없으면 같은 요구사항 묶음을 두 사람이 다르게 나누고, 그 차이가 코드 배치로 굳은 뒤에는 되돌리는 비용이 큽니다.
가장 흔한 기준은 요구사항 묶음입니다. 화면이나 업무 흐름이 하나면 컨텍스트도 하나로 잡는 방식입니다. 이 기준을 쓰면 다음이 발생합니다. 한 유스케이스가 다른 컨텍스트의 애그리거트를 변경해야 하는데, 그 애그리거트의 불변식을 누가 지키는지가 정해지지 않습니다. 두 컨텍스트가 같은 데이터를 각자의 규칙으로 바꾸기 시작하면 트랜잭션 경계도 함께 흐려집니다.
결정
경계를 새로 그을 때의 판정 기준은 애그리거트 소유입니다. 어떤 유스케이스가 어느 컨텍스트에 속하는지는 그것이 어느 애그리거트를 변경하는가로 정합니다.
| 상황 | 판정 |
|---|---|
| 유스케이스가 A 애그리거트를 변경한다 | A의 소유 컨텍스트에 속합니다 |
| 유스케이스가 A와 B를 함께 변경한다 | 경계를 잘못 그었거나 트랜잭션을 나눠야 합니다 |
| 유스케이스가 B를 읽기만 한다 | 소유와 무관합니다. 계약이나 조인으로 해결합니다 |
이미 그은 경계를 재검토할 때는 다른 세 질문을 씁니다. 용어가 다른가, 함께 변경되는가, 따로 살 수 있는가입니다. 셋 다 아니면 경계를 잘못 그은 것이므로 합칩니다.
두 기준은 경합하지 않고 시점이 다릅니다. 애그리거트 소유는 신규 판정이고 세 질문은 사후 검토입니다. 애그리거트 소유는 세 질문 중 "따로 살 수 있는가"의 구체적 형태이기도 합니다.
검토한 대안
요구사항 묶음으로 나눈다
| 구분 | 내용 |
|---|---|
| 장점 | 요구사항 문서와 컨텍스트가 1:1로 대응해 추적이 쉽습니다 |
| 단점 | 같은 애그리거트를 두 컨텍스트가 변경하게 되어 불변식의 소유자가 사라집니다 |
| 기각 사유 | 판정 기준이 배치를 정해 주지 못합니다. "이 유스케이스는 어디에 두는가"에 두 답이 가능해집니다 |
세 질문만 쓴다
| 구분 | 내용 |
|---|---|
| 장점 | 경계의 실재 여부를 다각도로 확인합니다 |
| 단점 | 세 질문 모두 이미 있는 경계를 전제합니다. 아무것도 없는 상태에서 첫 선을 그을 때는 답할 수 없습니다 |
| 기각 사유 | 단독으로는 신규 판정에 쓸 수 없습니다. 기각이 아니라 역할을 재검토로 한정했습니다 |
결과
새 유스케이스의 배치가 결정적으로 정해집니다. 무엇을 변경하는지만 보면 되므로 재량이 들어가지 않습니다.
감수하는 것은 애그리거트를 먼저 식별해야 한다는 선행 조건입니다. 도메인을 충분히 이해하기 전에는 애그리거트가 잘 보이지 않으므로, 초기에는 경계를 크게 잡고 나중에 나누는 편이 안전합니다. 합치는 것보다 나누는 것이 쌉니다.