web-dev-qa-db-ja.com

クラスが多すぎずにWPFアプリケーションでMVVMとDDDを使用する

プレゼンテーション層にMVVMを適用し、アプリケーション全体にDDDを適用したいWPFアプリケーションがあります。アーキテクチャをどのように適用すべきかについて、私は非常に混乱しています。次のデザインを試してみると、現時点では完全に混乱しているように感じますので、アドバイスをいただけますか。

私は4つの層を持っています：

  • _Presentation Layer_：これは私のWPFクライアントアプリケーションが存在する場所です。

  • _Application Layer_：これは、ビジネスルールのドメインサービスと通信することになっているサービスがあり、CRUDを実行する場所です。これは、PresentationとDomainの間の腐敗防止レイヤーとして機能します。 レイヤー。

  • _Domain Layer_：ここに、集計、​​ドメインオブジェクト、およびIsTooOld(Person person)などのビジネスルールを明らかにするいくつかのサービスがあります。

  • _Infrastructure Layer_：これは最下層であり、インフラストラクチャはここにあり、IRepository、IEntityなどです。 。

これらのDDDベースのレイヤーを使用して簡単なシナリオを実現しましょう。データベースにPersonオブジェクトを配置し、マップし、データベースをCRUDし、人の誕生日を確認して、ユーザーに表示します。

プレゼンテーション層

WPFの部分から始めましょう。次のクラスを作成します。

  • PersonView：人のXAMLビュー

  • PersonViewModel：ViewModelに機能を提供するPersonView。 PersonViewはこれにバインドし、このViewModelはPersonModelからの値を提供します

  • PersonModel：これは私のPersonViewModelが緊密に結合されているMVVMモデルです。

ドメインレイヤー

これは、プレゼンテーション層には十分です。データベースに接続して、personオブジェクトを取得して表示したいと思います。

私は作成する必要があります：

  • PersonEntityin _Domain Layer_：データベースとのマッピングに使用されるデータベースエンティティの集計。 Domainレイヤーにあります。

  • Personin _Domain Layer_：これはDDDのドメインモデルです。ここにいくつかのロジックを配置しますが、DDDが示唆するようにエンティティオブジェクトを送信したくありません。

アプリケーション層

わかりました、私はすでに互いにかなり似ている3人のモデルを持っています。データアクセスとサービスについてはどうですか？

  • PersonServicein _Application Layer_：プレゼンテーション層がこの層と通信したい場合は、そのPersonModel（MVVMモデル）からPerson（ドメインモデル）。次に、アプリケーション層のこのサービスは、Person（ドメインモデル）をPersonEntity（エンティティオブジェクト）に変換し、データベースでCRUDを実行します。このサービスは、ドメインレイヤーで別のPersonService（以下を参照）を使用して、いくつかのビジネスルールをチェック/適用します。

  • PersonServicein _Domain Layer_：このレイヤーはPersonドメインオブジェクトでのみ機能します。 bool IsTooOld(Person person)のようなビジネス関連のルールがあります。

要約すると、私は単純なシナリオで7つのクラスになりました。

  1. _Presentation.WpfClient.View.PersonView_
  2. _Presentation.WpfClient.ViewModel.PersonViewModel_
  3. _Presentation.WpfClient.Model.PersonModel_
  4. _Application.ApplicationServices.PersonService_
  5. _Domain.Application.Services.PersonService_
  6. _Domain.Application.Models.Person_
  7. _Domain.Application.DbEntities.PersonEntity_（これを作成した理由は、複雑なドメインオブジェクトのマッピングを使用できないため、ドメインオブジェクトをマッピングする代わりに、ここにいくつかのデータ注釈を配置するだけです）

これは非常にぎこちなく感じます。それをどのように再構築し、ドメイン駆動設計とMVVMパターンの両方に利益をもたらすべきかわかりません。私は本当に行き詰まっていて、MVVMとドメイン駆動設計の両方を適用するためのアドバイスや実際の例を本当に楽しみにしています。また、簡単な操作でこれだけの作業を最小限に抑えるための命名規則や戦略についてのフィードバックも受け付けています。

私はまだ2つの具体的な質問があります：

  1. プレゼンテーション層からモデルを削除し（MVVMモデル）、ドメイン層からのモデルのみを使用する必要がありますか（DDDモデル）？この時点でMVVMに違反していませんか？

  2. エンティティ（データベース）モデルをドメインモデルとマージする必要がありますか？ DDD違反ではないですか？

更新

私が下した決定：

最後に、次のようになります。

  1. _Presentation.WpfClient.View.PersonView_
  2. _Presentation.WpfClient.ViewModel.PersonViewModel_
  3. _Application.ApplicationServices.PersonService_（アプリケーション関連のロジックを含むクラッド）
  4. _Application.ApplicationServices.Mappings_（ここにリポジトリの抽象化とマッピングがあります）
  5. _Domain.Application.People.Person_（制限されたコンテキスト内の個人オブジェクト、オブジェクトはドメインロジックを処理するのに十分スマートです）
wpfdesign-patternsmvvmarchitecturedomain-driven-design
17
U. Bulle

これは、単一の概念にはクラスが多すぎます。

プレゼンテーション層からモデルを削除し（MVVMモデル）、ドメイン層からのモデルのみを使用する必要がありますか（DDDモデル）？この時点でMVVMに違反していませんか？

はい、これは多くの場合、特にWCFのような通信メカニズムを使用しない場合に望ましい解決策です。 MVVMはモデルパーツの特定の実装を強制しないため、ここでは違反はありません。

エンティティ（データベース）モデルをドメインモデルとマージする必要がありますか？ DDD違反ではないですか？

また、はい。エンティティを2つ（ドメインエンティティと「永続性」エンティティ）に分離すると、通常、過度の複雑化と貧血のドメインモデルが発生します。これについての詳細は次のとおりです。 ドメインモデルを永続性モデルから分離する 。

全体として、 this の例を確認することをお勧めします。これはまさにあなたが必要としているもののように見えます：MVVMとDDDを使用してWPFで書かれた本格的なアプリケーション。

11
Vladimir

DDDは、複雑なビジネス上の問題を処理するのに最も有益です。実際のプロジェクトでは、ドメインの複雑さに応じて、より柔軟な方法で使用する必要があります。それを採用するために、複数の戦略のアプローチを使用したいと思います。

  1. ほとんどの場合、データ構造の変更がほとんどないCRUDデータに関するものです。私は使用するだけです：

    プレゼンテーション層：ViewModel
    サービスレイヤー：ViewModel <-> Dominオブジェクト
    ドメインレイヤー：エンティティと同じドメインオブジェクト

  2. ドメインオブジェクトに重要で再利用可能なビジネスロジックが多数ある、より複雑なドメインの場合は、コアサービス（Domain.Application.Services.PersonServiceなど）を追加します。

  3. プレゼンテーション層とドミン層の間でデータを簡単にマッピングするために、プロセスデータに必要な複雑なビジネスロジックもある場合。 Presentation.WpfClient.Model.PersonModelと同様に、サービスレイヤーに別のモデルを追加します。

つまり、基本的に、現在使用しているアーキテクチャは、Personドメインがプロジェクト内で非常に複雑な場合に対処する準備ができています。しかし、私はあなたの説明からそれを今のところ見ることができません。

あなたの質問に答えるには：

  1. MVVMモデルのPresentation.WpfClient.Model.PersonModelを削除できます。この場合、ドメインオブジェクトはモデルであり、ViewModelとしてPresentation.WpfClient.ViewModel.PersonViewModelがあるため、MVVMに違反しません。

  2. Personドメインに複雑なビジネスロジックがない場合は、EntityをDomainオブジェクトとマージできます。

2
codigube

最初の質問では、ドメインレイヤーモデルをMVVMモデルとして使用しても、MVVMに違反することはありません（ モデルの定義はこちらを参照 ）

このテーマの詳細と2番目の質問への回答については、次を参照してください。 エンティティVSドメインモデルVSビューモデル

1
Timothy Ghanem