답변출처·10단계

DEV CommunityModeling Shared Entities Across Bounded Contexts in ...

dev.to favicon

PikoPostExamples of shared kernel in Domain Driven Design - PikoPost

pikopost.com favicon

Adonis MediaUsing Two Domains for One Website: Benefits & Best Practices

adonis.media favicon

Software Engineering Stack ExchangeDDD Referencing objects from other bounded contexts

softwareengineering.stackexchange.com favicon

도메인 주도 설계(DDD) 관점에서, 메뉴(Menu) 엔티티가 게시판, 가게 등 여러 도메인(바운디드 컨텍스트)에서 사용된다면,메뉴 엔티티의 위치는 다음 원칙에 따라 결정하는 것이 좋습니다.

1. 바운디드 컨텍스트별 독립 모델링이 기본

• DDD에서는 **각 바운디드 컨텍스트(도메인)**가 자신의 목적과 요구에 맞게 엔티티를 독립적으로 모델링하는 것을 권장합니다.
  • 즉, 게시판의 메뉴와 가게의 메뉴가 의미적으로 다르거나, 포함하는 속성/행위가 다르다면 각 컨텍스트에 별도의 Menu 엔티티를 두는 것이 바람직합니다.
  • 예시:
    • 게시판 메뉴는 카테고리, 접근권한, 게시글 수 등과 연관될 수 있음
    • 가게 메뉴는 음식명, 가격, 재고, 옵션 등과 연관될 수 있음
• 공통된 이름(Menu)이라도, 실제로는 각 도메인에 특화된 모델이 되는 것이 자연스럽습니다1.

2. 진짜로 완전히 동일한 개념이라면?

• 두 도메인에서 메뉴의 의미, 속성, 행위가 완전히 동일하다면,

  "Shared Kernel" 패턴처럼 **공통 모듈(공유 커널)**에 Menu 엔티티를 두고

  각 도메인에서 이를 참조할 수도 있습니다2.

  • 단, 이 방식은 두 도메인 팀이 강하게 협업하고, 변경에 대한 합의가 가능한 상황에서만 권장됩니다.
  • 그렇지 않으면, 도메인 간 결합도가 높아져 유지보수가 어려워집니다.

3. 결론 및 추천

• 실제로 각 도메인(게시판, 가게)에서 메뉴의 의미와 요구사항이 다르다면,각 도메인 내부에 Menu 엔티티를 별도로 두세요.
  • 예시:
    • board.menu.Menu
    • store.menu.Menu
• 정말로 완전히 동일한 모델이라면,두 도메인에서 공유하는 별도의 공통 모듈(Shared Kernel)에 위치시키고,각 도메인에서 의존하도록 할 수 있습니다.
  • 단, 이 경우에도 도메인 간 결합과 변경 비용을 신중히 고려해야 합니다.

“Rather than forcing a single entity to serve multiple masters, DDD encourages modeling the concept according to the specific domain's needs.”— 1

요약: