web-dev-qa-db-ja.com

ドメイン駆動設計-開発者の作業の改善

3つのレイヤーがある.netアプリケーションのアーキテクチャに出くわしました

Repository layer (edmx and their classes)
      ^
      |
      V
Domain layer (Model -> Interfaces and their implementation)
      ^
      |
      V
Web layer (Model -> View models)

Webとデータレイヤー間の通信は、ドメインレイヤーで定義されたインターフェイスを介して行われます（ 貧血モデル ）

ここで使用される命名規則は、すべてテーブル名に依存しています

リポジトリレイヤー

TableNameRepository.cs

TableName.cs（自動生成ファイル）

DomainLayer

ITableName.cs

TableName.cs

TableNameService.cs

Webレイヤー

TableNameListModel

TableNameAddEditModel

この問題は、テーブルで列が変更された場合、リポジトリレイヤーとドメインレイヤーのすべてのクラスを再処理する必要があることです。

また、これらのレイヤー間の通信は、Containerが静的である次のように解決されたマネージャーと行われます

Container.Resolve<RepositoryManager>();
Container.Resolve<ServiceManager>();

DBContextは、最初の呼び出し中にセッション変数に格納され、要求の最後に削除されます。 2番目の呼び出しは、new演算子を使用してDBContextを初期化します。

DDDと整合するようにこのアーキテクチャを強化するために、最小限の変更で何ができるかに関する提案。

design-patternsobject-oriented-designdomain-driven-designasp.net-mvcsolid
6
gvk

例からはわかりにくいですが、これはかなり標準的なデザインのようです。

私の唯一の懸念は、通常はリポジトリに隠されているマネージャークラスとdbContextに関係しています。

「より多くのDDDを作成する」ことに関しては、DDDがOOになり、本質的にサービスレイヤーをエンティティオブジェクトに移動することを望んでいるという問題があります。しかし、これはサービスへのステートレスコールに基づくweb/web.apiサービス。

ただし、名前を付けるだけの問題であり、サービスオブジェクトをデザインに含めることで解決できるため、あまり心配する必要はありません。つまり、注文を購入する（Order.Purchase()）ではなく、Tillが注文を完了します（Till.Complete(order)）

問題＃1

「テーブルで列が変更された場合、リポジトリ層とドメイン層のクラスはすべて再処理が必要です。」

これは当然のことですが、データベースにはモデルが格納されているため、一方を変更した場合は他方を変更する必要があり、その逆も同様です。

レガシーデータベースシステムを使用している場合、リポジトリでテーブルではなくストアドプロシージャを直接呼び出すことで、問題をある程度回避できます。これにより、テーブルとモデルの間に（追加の）抽象化レイヤーが提供されます

問題＃2

これらのレイヤー間の通信は、コンテナが静的である以下のように解決されたマネージャーと行われます

これは少し悪いです。コンテナーを認識し、必要なクラスを取得して挿入する（C＃mvcコントローラーを想定していますか？）Webレイヤーをインスタンス化するには、Factoryクラスを使用する必要があります。これにより、静的参照とその呼び出しが回避されます。

1
Ewan

まず、紙の練習から始めます。アーキテクチャを完全に理解できるように、完全なオブジェクトモデルを引き出します。

次に、明らかになった自然な境界のあるコンテキストがあるかどうかを確認しようとしました。次に、必要に応じて新しいドメインクラスを使用して、既存のコードと一緒に新しい境界付きコンテキストを実装し、ドメインオブジェクト内にビジネスルールをカプセル化します（これらのルールは別の場所にあると想定）。

すべてがうまくいくと仮定すると、新しい境界付きコンテキストは既存のコードの特定の部分を置き換えることができるはずです。これは後で削除できます。

その後、必要に応じて繰り返します。

個人的には、私が行った仮定を検討するのに役立つので、私が進むにつれてTDDを行いました。

0
Stewart Ritchie