역할 분담과 경계면

백엔드를 두 도메인으로 갈랐습니다. 나눈 기준은 사람이 아니라 바뀌는 이유입니다. 지도 규칙이 바뀌는 것과 콘텐츠 정책이 바뀌는 것은 서로 다른 사건이라, 한쪽 변경이 다른 쪽 코드를 건드리지 않게 했습니다.

Owner A — 지도 인프라

좌표를 격자로 바꾸고, 격자에 이름과 통계를 붙이고, 뷰포트 단위로 읽어 내리는 쪽.

패키지	역할
grid	좌표 → 격자 변환, 격자 등록, 뷰포트 조회
region	행정동 라벨과 지역별 수집률 집계
search	자유 텍스트 장소 검색 (카카오 로컬 프록시)
hotzone	최근 48시간 업로드 신호 집계와 상위 격자 조회
zone	"서면 A-14" 같은 사람이 읽는 격자 표시명의 구역 사각형

Owner B — 콘텐츠 · 인증

사용자가 누구인지 확인하고, 영상을 받아 저장하고, 그 결과로 도감과 보상을 움직이는 쪽.

패키지	역할
auth	소셜 로그인, 토큰 발급·갱신
user	프로필, 닉네임, 도감 색상
video	업로드 발급·확정, 공개범위, 재생 URL
usergrid	개인 점령 상태와 롤백
badge · streak · mission	뱃지 조건, 연속 업로드, 축제·코스 미션
notification	FCM 발송, 카테고리별 옵트아웃
friend · moderation	친구 관계, 신고와 블라인드 처리

두 도메인이 만나는 곳

두 도메인은 서로의 엔티티나 리포지토리를 직접 부르지 않습니다. 오가는 것은 아래 계약 인터페이스뿐이고, 엔티티끼리의 연관관계 매핑도 만들지 않습니다. 참조는 gridId·userId 같은 값으로만 넘겨서, 경계가 클래스 수준의 의존으로 새지 않게 합니다.

계약	방향	언제
GridQueryService	B → A	영상 업로드가 좌표를 격자로 확정할 때. 콘텐츠 쪽은 격자 계산 규칙을 몰라도 됩니다.
UserGridQueryService	A → B	지도가 "이 사람이 점령한 격자"를 물을 때. 지도 쪽은 점령 판정 규칙을 몰라도 됩니다.

분담 라벨과 실제 구현자는 다른 축입니다

Owner A/B는 도메인 분담 라벨이지 누가 짰는지의 기록이 아닙니다. 계약 경계를 판정하고 작업을 배정할 때 쓰는 값이고, 실제 구현자는 git 이력과 이슈 담당자가 정본입니다. 실제로 둘은 자주 어긋났습니다. 어긋남은 오류가 아니라 분담과 작업 배분이 다르게 흘렀다는 사실입니다.