DDDリポジトリとREST

Question

DDDリポジトリは常に集計を返し、すべてが値オブジェクトとエンティティである必要がありますか？

たとえば、タイプとアイテムを持つInvoiceオブジェクトがあります。

Invoice 
    --Id 
    --Issuer 
    --InvoiceType 
    --Items 

データは4つのSQLテーブルに保存されます。

Invoices (FK to invoice type, FK to issuers), 
InvoiceTypes 
Items(fk to Invoice) 
Issuers 

リポジトリは常にそれで凝集体を返す必要がある場合は、完全な状態だ、私が50枚の請求書を取得し、唯一のIDとIssuerNameを表示する必要がある場合InvoiceTypeはやアイテムを含むようにやり過ぎのビットです。

InvoiceRepository 
{ 
    //should this also fetch InvoiceTypes and items from SQL, or i need separate invoice model for this 
    public List<Invoice> FetchForListing(int page, int take); 
} 

Answer 1

ため

例は、DDDリポジトリは、常に集計を返す必要があり、すべてはそれが値オブジェクトとエンティティですか？

いいえ書き込みを実行する使用例では、完全な内部状態が必要であるため、変更が不変条件を満たしているため、すべてをロードする必要があります。

の読み取りのみを実行する場合は、完全な状態はまったく必要ではありません。引き出すデータに限定するのが妥当です。

（例えば：cqrsパターンを使用する場合、全く凝集体を触れない傾向にある読み出し、その代わりに、より適切な表現に凝集状態の「突起」からデータをコピーする。）が

InvoiceRepository 
{ 
    // should this also fetch InvoiceTypes and items from SQL, 
    // or i need separate invoice model for this 
    public List<Invoice> FetchForListing(int page, int take); 
} 

この場合には、それはあなたが望むものではないので、あなたは、List<Invoice>を返さないだろう、とあなたは何を把握するために、独自のユビキタス言語でリポジトリ

InvoiceSummaryRepository 
{ 
    public List<InvoiceSummary> readSummary(int page, int take); 
} 

チェックを表現するために同じインターフェイスを使用していない可能性がありますInvoiceSummaryが実際に呼び出され、List<InvoiceSummary>が実際には独自の名前を持つものであるかどうかを判断します（これを使用して、REST APIのリソースの表現を作成する可能性があります）。