0

集約ルートに基づいてデータリポジトリを実装しようとしています。ただし、これが最善の方法かどうかはわかりません。フィードバックが必要です。

これが私が思いついた私のシステムの総体的なルーツです（以下にインデントされた子供たちが含まれています）

Customer (Has Data Repository)
    CustomerAccount
    CustomerAccountPerson
    CustomerOptions
    CustomerCustomField
    CustomerCustomFieldData
    CustomerFile
    CustomerNote
    CustomerLoginLog
    ..... and more
Order (Has Data Repository)
    OrderLineItem
    OrderStatusLog
    OrderFlag
    OrderOutsourcing
    ..... and more
Lead (Has Data Repository)
    LeadNote
    LeadSource
    LeadStatus
    LeadStatusLog
    ..... and more
Invoice  (Has Data Repository)
    InvoiceOrder
    InvoicePayment

さらに...私が抱えている苦労は、適切なデータリポジトリが集約ルートに基づいている場合、技術的には、顧客リポジトリに注文リポジトリを使用させ、顧客と注文用に2つの別々のリポジトリを用意する代わりに、顧客を用意する必要があるということです。 、注文が含まれています

私がそれを分離した唯一の理由は、顧客と注文データリポジトリの下に多数のサブテーブル/アイテムがあるためです。

他の人がデータリポジトリを設計するときにこのような状況をどのように処理するか、および他の人が私に提案する可能性があることを聞くことに本当に興味があります。

前もって感謝します。

4

1 に答える 1

2

ユースケースを知らずに判断することは不可能です。

集約ルートは、アクションを全体として実行できる論理ユニットを表します。

注文がスタンドアロンである場合、それは集約ルートである必要があります。それができない場合は、すべきではありません。たとえば、LineItemは順序外では意味がありません。ただし、注文は通常、顧客オブジェクトなしで使用できます。たとえば、出荷部門は顧客に関係なく注文を出荷済みとしてマークできるため、通常はARです。

DDDを（良いか悪いかにかかわらず）実行しようとする場合、設計は基盤となるデータテクノロジとテーブルレイアウトによって駆動されるべきではありません。RDBMSを使用する必要があると誰が言いますか？

DDDに関する独創的な本は、もちろん、Eric Evansの「ドメイン駆動設計」であり、人々がDDDをカーゴカルトし始めると、通常は失われる多くのコンテキストを提供します。

ジミー・ニルソンの「ドメイン駆動型の設計とパターンの適用」の本も頻繁に推奨されますが、個人的にはそれほど良いとは思いません。

DDDは、エンティティの状態でエンコードされていない多くのビジネスルールと動作/ロジックを含む複雑なドメインがある場合に役立ちます。ほとんどのアプリケーションはそれよりもはるかに単純であり、より優れた設計の選択肢があります。

MartinFowlerの優れた本「PatternsofEnterpriseApplication Architecture」を読むことをお勧めします。これは、DDDの本よりも広い範囲をカバーし、バックエンドからGUIまで、すべてのアプリケーション層をカバーするだけでなく、アプリケーションの動作を処理するための多くの優れたアプローチを提供します。

于 2013-03-08T16:06:44.733 に答える