dpdpdndn 블로그

ADR-002 도메인 관계 유형과 허용 의존 방향

NEW5 min read

ADR-002 도메인 관계 유형과 허용 의존 방향

  • 상태: 채택
  • 날짜: 2026-07-03
  • 근거: PRD FR-2, FR-3 / TDD “도메인 관계 유형·허용 의존 방향”

맥락

도메인 간 참조 규칙(ID-only, common 예외)이 일반 원칙으로만 존재하고, 실제 도메인 쌍에 대한 관계 유형·의존 방향 표가 없다. 실측 결과 domain 레이어 교차 import는 0건이며, 동기 협력은 application 오케스트레이션·Gateway interface로, 비동기는 도메인 이벤트로 이뤄진다.

결정

핵심 의존 규칙 5개를 확정한다.

  1. domain 레이어는 타 도메인을 import하지 않는다 — common만 예외. 도메인 간 데이터 참조는 ID(Long)만.
  2. 도메인 간 협력은 두 경로만 — ① application 오케스트레이션 ② 도메인 이벤트(비동기).
  3. 코어 → 코어 동기 호출은 소비자가 정의한 Gateway interface(ACL) 를 통한다. 공급자 Entity 직접 참조 금지. (예: booking의 PaymentRefundGateway, payment의 OrderConfirmationGateway)
  4. 지원·서브시스템(notification/operator/mcp/weather/alerting)은 코어를 동기 호출하지 않는다 — 코어 이벤트를 소비하는 단방향만. (⑥ alerting은 코어 동기 미호출 + notification DISCORD 채널을 이벤트 경유 재사용, domain.notification 미import) 명시 예외 3건(R3 화이트리스트): ① dashboard → 코어 읽기 전용 조합 ② application.partner → domain.user(② B2B) admin 프로비저닝 쓰기 오케스트레이션(CreatePartnerUseCase가 연동 전용 User 계정 생성). rule #2(application 오케스트레이션 허용) 범위지만 dashboard 읽기보다 넓은 쓰기 예외이므로 화이트리스트에 명시 등록. ③ application.featureflag → domain.user 읽기 전용 조합 — GetFeatureFlagAuditLogsUseCase가 감사 로그 변경자를 내부 PK 대신 표시 이름으로 보이려고 UserDomainService.findDisplayNamesBy를 호출한다(2026-08-04 등록). 근거: 의존이 domain.user 하나이고 읽기 전용이며(①과 동일 성격), featureflag·user가 물리 분리 목표 토폴로지에서 같은 서비스(platform) 에 속해 서비스 간 동기 결합을 만들지 않는다. domain.featureflag는 코어를 전혀 의존하지 않음을 별도 ArchUnit 규칙으로 고정한다(조합은 application 레이어에만 허용).
  5. operator·mcp 격리 — 코어↔서브시스템의 유일한 결합은 코어→서브시스템 이벤트 단방향.

관계 유형 표(요약):

소비자 → 공급자관계통신
booking/goods/ticketing → paymentCustomer-Supplier동기(app/Gateway)
payment → 코어Conformist(ACL)OrderConfirmationGateway 콜백
facility → bookingCustomer-Supplier동기(app)
dashboard → 코어5Conformist(읽기)app 조회 조합 (R3 예외)
partner → user (② B2B)Customer-Supplier(쓰기)app 오케스트레이션 CreatePartnerUseCase (R3 예외)
featureflag → userConformist(읽기)app 조회 조합 GetFeatureFlagAuditLogsUseCase (R3 예외)
코어 → notification/mcp/operator발행-구독이벤트(비동기)
alerting → notification (⑥)발행-구독(발송 재사용)이벤트→presentation→application, DISCORD 채널, ID 참조만

근거

  • 실측 의존이 이미 이 규칙을 따르고 있음(교차 import 0건) → 규칙은 현상 유지 + 회귀 방지가 목적.
  • Gateway 역전(ACL)으로 payment가 코어를 import하지 않고도 콜백 가능 → 순환 의존 차단.
  • 지원·서브시스템의 코어 동기 호출을 금지해 코어의 안정성을 보호(지원이 코어를 오염시키지 않음).

대안 (미채택)

  • 도메인 간 직접 동기 호출 허용(Entity 공유): 순환 의존·강결합 유발. FR-7 베이스라인 0건 파괴.
  • 모든 협력을 이벤트로 강제: 조회성 동기 조합(dashboard)까지 이벤트화하면 과도한 복잡도. 단순함 우선 위반.

영향

  • FR-7 ArchUnit 규칙 R1~R4가 이 결정을 코드로 강제(ADR-005).
  • 후속 ② B2B 과제가 “지원 도메인(Partner) → 코어(goods/ticketing) 제공 UseCase 호출” 방향을 이 규칙으로 인용.

그래프 뷰