脂肪ドメインモデル=>非効率ですか？

Question

DDDを見ると、私たちはデータベースをさまざまなモデルに抽象化し、それを操作しているモデルを、モデルが存在するリポジトリとして見ます。次に、その上にデータレイヤーとサービス/ビジネスレイヤーを追加します。私の質問は、そうすることで、太ったモデルを構築してデータ転送の非効率性を作り出しているということですか？

たとえば、顧客の請求書を画面に表示するシステムがあるとします。 OOPの用語で、それの 思考、我々はおそらく多少このようになりますオブジェクトで終わるだろう：請求書はもっぱら顧客名を印刷する必要がある場合

class Invoice { 
    Customer _customer; 
    OrderItems _orderitems; 
    ShippingInfo _shippingInfo; 
} 

class Customer { 
    string name; 
    int customerID; 
    Address customerAddress; 
    AccountingInfo accountingInfo; 
    ShoppingHistory customerHistory; 
} 
    (for the sake of the question/argument, 
    let's say it was determined that the customer class had to 
    implement AccountingInfo and ShoppingHistory) 

、なぜ我々はすべて運ぶだろうそれと他の手荷物？リポジトリ・タイプのアプローチを使用すると、これらのすべてのリソース（CPU、メモリー、複雑な問合せ結合など）を必要とする複雑なドメイン・オブジェクトを構築し、それをクライアントに送信するようです。

請求書クラスにcustomerNameプロパティを追加するだけでは、抽象概念から逸脱することになり、ひどい習慣のように思えます。 3番目の手では、顧客のようにオブジェクトを半分塗りつぶすことは、同じオブジェクトの複数のバージョンを作成してしまう可能性があるため、非常に悪い考えです（たとえば、住所はありますがShoppingHistoryはなく、AccountingInfoはありません住所など、など）。私は何が欠けているか、または理解していないのですか？

Answer 1

優れたオブジェクトリレーショナルマッパーは関係を怠惰に読み込むことができるため、請求書の顧客を引き取っても、会計およびショッピングの履歴は無視されます。 oject-relational mapperを使用していない場合は、自分自身をロールバックすることができます。

トラザクションの境界を超えて（データベースのトランザクションを終了した）、クライアント内でこれを行うことはできないため、適切なデータがロードされているかどうかはサービスレイヤーに依存します。

サービス層の単体テストでは、適切なデータが利用可能であり（それほど多くはない）、しばしば適切です。

Answer 2

お客様のクラスにはAccountingInfoとShoppingHistoryを実装する必要があると判断されたため、請求書を明示的に表示することはシステムが実行する唯一のタスクではありません（他の機能さもないと？-）。

とにかく（他の機能のために）顧客テーブルが必要です。もちろん、インボイスプリンタは、他の機能で使用されているものと同じテーブルから顧客データ（名前だけ）を取得する必要がありますシステム内で

"オーバーヘッド"はまったく幻想的です.1つの機能を単独で見ると存在するように見えますが、システム全体を統合された全体として見るとまったく存在しません。