3

私は通信会社の大規模システムに取り組んでいます。私はDDDを初めて使用し、さまざまな部分をリンクするのに苦労しています。現在のシステムはNHibernateを使用して構築されています。現在600をはるかに超えるテーブルがあり、すべてのデータアクセスはNHibernateを使用して行われますが、新しいシステムではEFを使用します。以下は、いくつかの機能領域と、各機能領域のデータベーステーブルの例です。

顧客
----->CustomerDemographics
-----> CustomerPayments
-----> CustomerTransactions

RoutingEngine
-----> InboundRoutes
-----> OutboundRoutes

ProvisioningEngine
----- > InboundSwithces -----
> OutboundSwitches
-----> RouterConfigs
-----> GatewayConfigs

BillingEngine
-----> InboundTraffic
-----> OutboundTraffic

システムはユニットテスト可能でなければならないので、リポジトリパターンを使用して実際のエンティティを抽象化し始めました。1つのアプローチは、データベーステーブルごとに1つのリポジトリオブジェクトを作成することです。もちろん、これらのリポジトリクラスはすべて、汎用リポジトリインターフェイスから派生させることができます。ただし、これにより、コードベースのメンテナンスに関してかなりのオーバーヘッドが追加されます。DDDでは、このアグリゲートの概念について読みましたが、EFのコンテキストで特別に適用する方法がわかりません。Aggregateオブジェクトは、これらのリポジトリーのコンテナーである必要がありますか、それとも関連するコンテキスト（Bounded DbContextsの線に沿った何かを意味する）のコンテナーである必要がありますか？

4

2 に答える 2

6

1つのアプローチは、データベーステーブルごとに1つのリポジトリオブジェクトを作成することです。

DDDでは、永続性の無知の概念により、データベーステーブルは通常、リポジトリとの1対1のマッピングではありません。代わりに、リポジトリは集計と1対1である必要があります。

もちろん、これらのリポジトリクラスはすべて、汎用リポジトリインターフェイスから派生させることができます。

リポジトリパターンは、滑りやすい坂道である可能性があります。カプセル化には最適ですが、不必要な抽象化に夢中になりがちです。別の視点については、こちらをご覧ください。

Aggregateオブジェクトは、これらのリポジトリーのコンテナーである必要がありますか、それとも関連するコンテキスト（Bounded DbContextsの線に沿った何かを意味する）のコンテナーである必要がありますか？

「機能領域」と呼ばれるものは、DDDでは有界コンテキスト（BC）と呼ばれているようです。（EFのDbContextではありません）。また、アグリゲートはリポジトリのコンテナではなく、ドメインモデルの関連エンティティのグループが含まれています。ステレオタイプの例は、注文集計ルートとさまざまなエンティティおよび注文明細などの値オブジェクトで構成される注文集計がある販売注文モデルです。上記のように、アグリゲートはリポジトリがアクセスを提供する必要があるドメインオブジェクトです。したがって、アグリゲートを中心にリポジトリを構築する必要がありますが、もちろん、最初にアグリゲートとBCを特定する必要があります。VaughnVernonによる効果的な骨材設計をご覧ください。

また、1つのBCに600のテーブルがあることは多すぎるように思われ、複数のBCがプレイされていることを示す可能性があります。BCが達成するのは機能的凝集度であり、これはリポジトリをグループ化する（DDD用語との「集約」競合）ための最も適切な方法です。

于 2012-10-16T17:22:49.867 に答える
2

DDDの集約は、整合性の境界、つまりトランザクションの整合性の島です。ドメインモデルにオブジェクトのクラスターがあり、トランザクションの一貫性を維持し、意味のある概念全体として扱うことができる場合は、集約が存在する可能性があります。アグリゲート全体で、結果整合性を持たせることができます。

新しい開発を行う場合は、最初にオブジェクトでドメインをモデル化してから、後のパスとしてデータベーススキーマを理解することをお勧めします。

1つの巨大なモデルを、おそらく機能分野の幅広いラインに沿って、より多くの特殊なドメインモデルに分割し、各モデルが処理することを目的とした主要なビジネスシナリオ（つまり、各モデルで解決しようとしている困難なビジネス上の問題）に注意することをお勧めします。 ）。各モデルは、その周囲に適切な境界を設定する必要があります（つまり、明示的に定義された境界コンテキスト内にある必要があります）。ここで、あるモデルに属するものと別のモデルに属するものが明確になります。これは通常、モデルの境界をある種のサブシステムの境界に揃えることによって実現されます（アーキテクチャ的に言えば）。

于 2012-10-17T04:49:30.507 に答える