왜 Bounded Context부터 나눴는가
이번 프로젝트는 기능 수보다 역할이 많은 시스템이었다.
예약, 고객, 결제, 지점 운영, 본사 관리가 한 코드베이스 안에 함께 존재하기 때문에, 경계를 먼저 나누지 않으면 변경이 겹치는 지점이 급격히 늘어난다.
그래서 초기 설계에서는 화면 흐름보다 먼저 다음 질문을 봤다.
- 어떤 개념은 같은 단어를 쓰지만 실제 책임이 다른가
- 어느 데이터는 함께 바뀌고 어느 데이터는 독립적으로 바뀌는가
- 어떤 변경 요청이 자주 함께 들어오는가
이 기준으로 모델을 나누면, 기능 추가 시 "어디에 넣어야 하는가"가 훨씬 빨라진다.
14개 컨텍스트를 나눈 기준
14개라는 숫자 자체가 목표는 아니었다. 중요한 것은 경계가 설명 가능해야 한다는 점이었다.
- 고객 접점과 내부 운영 규칙은 서로 다른 언어를 가진다
- 본사 관점의 통계/정산과 지점 관점의 실무 처리는 우선순위가 다르다
- 예약/결제/회원 상태는 맞닿아 있지만 동일한 생명주기를 갖지 않는다
이렇게 나눈 컨텍스트는 이후 API와 데이터 계층의 책임 분배 기준이 되었다.
모델링이 이후 설계에 준 영향
도메인 모델링은 문서 한 장으로 끝나는 단계가 아니었다. 이후 설계 대부분이 이 경계를 그대로 따라갔다.
- 데이터 계층에서는 컨텍스트별 저장소와 쿼리 범위를 선명하게 유지했다
- 인터페이스 계층에서는 어떤 요청이 어느 유스케이스에 속하는지 구분이 쉬워졌다
- 운영 단계에서는 장애가 특정 컨텍스트 문제인지 더 빨리 좁힐 수 있었다
결국 좋은 모델링은 예쁜 다이어그램이 아니라, 이후 구현 의사결정을 줄여주는 기준선이었다.