1

Product と Payers のコレクションを取得しました。支払人は、3 つの異なる方法で製品の支払いを行うことができます。ただし、パーセンテージを手動で設定するか、支払人の収入によって、または支払人のそれぞれの保有額によって支払います。製品の支払い方法は、製品の列挙型によって決定されます。

私の永続層では、Product、Payer、および ProductManuallyPaid の 3 つのクラスを取得しました。これは、Product が手動で支払われる場合、Product と Payer の間の多対多のクラスであり、各 Payer が支払わなければならないパーセンテージを指定します。

これをどのようにビューにマッピングすればよいですか? 新しい多対多クラス (支払人への参照、製品への参照、および支払人が支払うべき正確な金額で構成される) が必要ですか?

計算はサービス レイヤーで行う必要があると思いますが、サービス レイヤーは新しい多対多クラスが付加された製品/支払者の ViewModel/DTO バージョンを返す必要がありますか、それとも後で処理する必要がありますか? 後で処理する必要がある場合、エンティティにはその新しい多対多クラスのリストを含める必要がありますが、永続化レイヤーでは無視されますか?

4

1 に答える 1

3

DDD は、ER/データ モデルではなく、何よりもまずオブジェクト モデルの設計に焦点を当てた考え方を採用することを提案する場合があります。データ モデルがどのように見えるべきか (多対多テーブルなど) について考えたことがあると思いますが、最初にオブジェクト モデルがどのように見えるかを検討する必要があるかもしれません。次に、そのオブジェクト モデルがドメイン (ビジネス ロジック、ビジネス動作) を反映するので、そのオブジェクト モデルをデータベースにマップする方法を考えます。

たとえば、支払いのコレクションを持つ製品を返す方が理にかなっている場合があります。そして、各 Payment には Payer エンティティへのリンクがあります。設計によっては、Payer リンクにアクセスしたい Payer 情報のコピーが含まれている場合や、必要な情報/値を含む完全な Payer エンティティをロードする方法をリンクが知っている場合があります。さらに、各 Payer インスタンスには、Product にリンクする Payments のコレクション (上記と同じクラス タイプですか?) がある場合があります。

この設計は、OO プリンシパルをより有効に活用し、リレーショナル データベースよりも適切にドメインを記述します。さらに、これらのオブジェクトは、ネイティブ オブジェクト構造によって必要なものが論理的に提供されているため、サービスおよび UI レイヤーでの処理が容易になる場合があります。すなわち。製品には支払いがあり、支払い者などがあります。

私は自分で考えるDDDにかなり慣れていません。そして、DDD という言葉に怖がる前に、このEvan の本の要約版をご覧ください。読みやすく、無料でダウンロードできます。それはあなたが探していた宝石をあなたに与えるだけかもしれません.

于 2009-12-12T07:01:28.860 に答える