2012-02-03 3 views
1

저는 렌터카 웹 사이트의 도메인으로 ddd의 일부 측면을 연구하려고합니다.렌터카 도메인의 집계를 확인하려고 시도했습니다

사용자/고객이 시작 및 목적지 스테이션에서 차량을 선택합니다.

가격 계산은 지불 방법, 시간, 자동차 분류 등과 같은 다양한 요소에 따라 다릅니다. 데이터 액세스 전략이 다른 응용 프로그램과 다른 하위 시스템에서 데이터를 검색합니다. 역 서비스, 콜센터와 같은 도메인에 여러 배우가 있습니다

... 바운딩 문맥

아이디어

  • 회사 (직원, 자동차, 역)
  • 예약 (예약은 , 예약 요청 프로세스 모델)
  • 가격 (가격 모델)
  • 결제 (임대 청구, 위치, 고객)

경계 된 컨텍스트를 정의한 후 각각의 집계 된 루트가 맞는지 확실하지 않습니다. 모두 세

  • 예약 : 예약
  • 가격 (취급, 자동차 및 고객에 대한 접근) : 관세 매트릭스
  • 결제 : 고객 (예약에 대한 액세스, 취급 고 내 생각은

    • 회사입니다)

    필요한 경우 여러 가지 경계 다이어그램을 표시 할 수있는 클래스 다이어그램을 추가 할 수 있습니다. 자세한 정보가 필요하면 클래스 다이어그램 또는 다른 섹션으로 마이그레이션해야합니다. 자유롭게 물어보십시오.

  • 답변

    1

    내가 렌터카 도메인과 관련하여 경험 한 바가 없으므로 올바른 길을 가고 있다고 말할 수 있습니다. Bounded Context는 물리적 분리가 아닌 논리적 인 분리입니다. 따라서 구성 UI와 같은 것을 사용하면 예약 프로세스의 일부로 가격 정보를 표시 할 수 있습니다. 다른 BC에서 나란히 UI 구성 요소를 호스팅하고이를 사용하여 최종 사용자가 완료하려고하는 프로세스를 안내합니다. 다른 하나는 모든 BC에서 골재를 찾고있는 것이지만, 각각의 도메인 모델을 필요로하지 않는다는 것을 알기를 바랍니다. 물건이 비즈니스의 핵심 또는 본질적으로 기초가 아닌 경우 간단한 데이터 모델이 제공 할 수 있습니다. BC의 아름다움, 신중한 기술 선택의 능력.

    관련 문제