データモデルの設計とドメインモデルの設計

Question

食料品店をモデル化しようとしています。ストアには、いくつかの「通路」があります。各「通路」 「カテゴリ」のグループがあります。 「アイテム」の格納します。各「カテゴリ」 1つの「通路」にのみ属することができます。各「アイテム」 「カテゴリ」は1つしか持てません。

データモデルは私にとっては単純明快です：

• 「通路」 IDと説明を含む表
• ＆quot;カテゴリ＆quot; ID、NAME、および「通路」を参照するAISLE_IDを持つテーブル表
• ＆quot; item＆quot; ＆quot; category＆quot;を参照するID、NAME、DESCRIPTIONおよびCATEGORY_IDを持つテーブル

オブジェクトモデルは私が助けを必要とする場所です：

1. 通路オブジェクトには、カテゴリオブジェクトとアイテムオブジェクトのリストを含めることができます。
2. 通路オブジェクトには、カテゴリオブジェクトのリストを含めることができます。 Categoryオブジェクトには、Itemオブジェクトのリストを含めることができます。
3. 通路には、Itemオブジェクトのリストを含めることができます。 Categoryオブジェクトには、Itemオブジェクトのリストを含めることができます。

いずれの場合も、アイテムには論理的にCategoryオブジェクトが含まれます。各ドメインオブジェクトにDAOがあります。そのため、実行方法によっては、SQLが少し変わります。何か考えはありますか？

Answer 1

選択肢＃2に投票します。 ＃1または＃3よりも意味があります。

関係は双方向である必要があると思いますか？アイテムは、その親カテゴリと祖父母の通路が誰であるかを把握できる必要がありますか？

Answer 2

選択肢2に進みます。

通路の主な懸念は、通路に含まれるカテゴリです。どのアイテムがメンバーであるかを判断するのは、Categoryクラス次第です。これにより、各オブジェクトの抽象化レベルの一貫性が保たれます。通路はより高いレベルのオブジェクトであり、カテゴリはやや詳細なレベルであり、アイテムは最もきめ細かいです。

Answer 3

数2は、これらが3つだけのオプションである場合に最も意味があります。

このモデルを作成する場合は、次のモデルを使用すると思います（小さな修正、考えにできるだけ近づけるように努めます）：

通路オブジェクトはカテゴリオブジェクトのリストを持つことができ、カテゴリオブジェクトはその中にアイテムオブジェクトのリストを持つことができます。アイテムはカテゴリと通路に関連付けられます。

私の変更はデータ側にあるようです。

私がそうした理由は、誰かが「ちょっとこの特定のアイテムを探しているのに、どの通路にあるの？」と言うからです。 -1回の検索で答えが得られます。一方、データモデルでは2回のルックアップが必要になります。

少なくともそれは私が考える方法です。