過去にいくつかのショッピング カート システムを構築したことがありますが、最終的な注文の請求書が「購入済み」とマークされたショッピング カートになるように常に設計していました。カート内のアイテムを追加/削除/変更するためのすべてのロジックは、注文のロジックでもあります。すべてのデータは、データベース内の同じテーブルに格納されます。しかし、これは e コマース サイトを設計するための適切な方法ではないようです.. ドメイン モデルでショッピング カートを請求書から分離することの利点を誰か説明できますか?
これにより、多くの重複したコード、データベース内の余分なテーブルセットが発生し、システムがより複雑な注文に対応し始める必要がある場合に維持することが難しくなるように思えます (アイテムに対して選択されたオプションを指定するなど)。注文の価格/在庫状況/出荷時間を変更する場合と変更しない場合があります)。私が目にするすべての本や他の例は、これらの一見類似した2つの懸念を分離しているように見えるので、私は光を見ていないと仮定しています-しかし、私はそのようなことの利点についての説明を見つけることができません! 私が設計するシステムもそうで、最初の注文が確定した後に変更が加えられることがよくあります。後で (ただし、フルフィルメントの前に) アイテムが削除、交換、または追加されることは珍しくありません。