製品のグループを1つの製品として販売するためのデータモデル
次のようなデータモデルを使用したeコマースがあるとします。これにより、Saleは単一のProductの販売方法を説明できます。この分割により、製品を異なる方法で複数回販売できます（異なる価格設定、または異なる時点での提供）。これは、販売が単一の製品を販売している場合に最適です。
販売
- product_id（販売は製品に属します）
- 価格、セールの有効期限、マーケティングコンテンツなど、その他のオファーの詳細
製品
- 製品には多くの売上があります
- 名前、写真、メーカーの説明など、実際の製品の詳細
問題：このデータモデルを改善して、販売で多くの製品を使用できるようにするにはどうすればよいですか？
たとえば、製品Aの1つと製品Bの1つのバンドルを作成する場合、顧客がこれらのバンドルの数量= 3を必要とする場合、合計3つのAと3つのBを受け取ります。
または、単一の製品の倍数を販売することもできます。この場合、販売は製品Cの5に対して行われます。したがって、顧客がこれらのバンドルの数量= 3を希望する場合、15の製品Cを受け取ります。
これまでのところ最高のアイデアは、新しいテーブルを追加することです。これにより、バンドル内の内容を説明する多くの注文可能商品をセールで参照できるようになります。
注文可能
- 製品に属する
- 販売に属する
- バンドルの数量
しかし、この規模のリファクタリングは記念すべき仕事です。回数sale.productはさまざまな理由でコードベースに表示されますが、非常に大きなものです。また、すべてのケースをコードで修正する必要があり、おそらくプレゼンテーションも修正する必要があります。
ですから、このアプローチに過度にコミットする前に、まだ見たことのない希望のかすかな光があるのか、あるいはこの壮大なリファクタリングの痛みと危険が私の将来に満ちているのかと思います。
これまで、これを行う企業で私が見たのは、次の2つのアプローチのうちの1つです。
「バンドル」は別の製品です。独自の製品としてデータベースに入れられ、独自の製品として在庫に保管され、在庫から削除されて独自の製品として出荷されます。リファクタリングは必要ありませんが、故障した場合に個別に販売できる在庫の製品を拘束します。これは、バンドルとしてカスタマイズできるという長所があります。つまり、コストは個々の製品とは異なる場合があります。
「バンドル」は「Bill of Materials」であり、最終的に完成品になります。完全に異なるアプローチと多くのリファクタリングが必要ですが、棚にある個々の製品の完全性を維持します。個々の製品にはまだ1つのアイテム（それ自体）を含む独自の部品表が必要なので、多くの重複が発生します。
もしそれをしていたら、バンドルのアイデアを「クイックエントリー」として販売する方法を見つけるでしょう。 GUIマクロのような働きをします。製品のリストからバンドルを選択すると、必要な個別のラインアイテム（および数量）が請求書に自動的に追加されます。それを実装するには「Bill of Materials」が依然として必要ですが、システム全体をリファクタリングする必要はありません。