私はレンタカーのウェブサイトのドメインでdddのいくつかの側面を研究しようとしています。
ユーザー/顧客は、出発地と目的地の駅と期間から車を選択します。
価格の計算は、支払い方法、時間、車の分類など、さまざまなものによって異なります。データは、アプリケーションの他の部分とはデータアクセス戦略が異なるサブシステムから取得されます。
ドメインには、ステーションサービス、コールセンターなど、いくつかのアクターがいます...
制限されたコンテキストのアイデアは
- 会社（従業員、車、駅）
- 予約（予約、予約リクエストプロセスのモデル）
- 価格（価格モデル）
- 請求（レンタル請求、ポジション、顧客）
境界付きコンテキストを定義した後、それぞれの集約されたルートが正しいかどうかわかりません。私の考えは
- 会社：3つすべて
- 予約：予約（請求書、車、顧客へのアクセス）
- 価格：料金表
- 請求：顧客（予約へのアクセス、請求）
必要に応じて、クラス図を追加して、さまざまな境界コンテキストを表示できます。さらに情報が必要な場合は、クラス図またはこれを他のセクションに移行する必要があります。お気軽に質問/実行してください。