3

EntityDeveloperを使用して生成したドメインがあります。これにより、すべてのエンティティとデータベーステーブルが作成されます。NHibernateを使用して、リポジトリを介して公開されているエンティティにデータを入力します。次に、リポジトリを有用なサービスに集約するサービス層があります。このレイヤーは2つの方法で使用されます。1つは、Webレイヤーとの間の唯一の通信手段としてサービスを使用しており、いつかWCFのサービスを使用したいと考えています。現在、私は自分のWebレイヤーに取り組んでおり、自分のサービスと通信するための最良の方法を見つけようとしています。私のサービスは現在エンティティを返しています。私のWebレイヤーは、コントローラーのサービスを介してこれらのエンティティを取得しています。これはおそらくDRY/DDDではありません。サービスレイヤーはDTOを介してインターフェイスする必要があると想定しています。DTOは私のWCFサービスに最適です。私のWebレイヤーに関しては、私は

つまり、これが私のアーキテクチャのようになります。

Domain
  Entities
  Repository Interfaces
Infrastructure
  NHibernate
  Concrete Repositories
Services
  DTO's
  Concrete Services
  Service Interfaces
  IIS hosted WCF
Website
  ViewModels

そして、AutomapperまたはValueInjecterを使用してマッピングを行います（エンティティ/ DTOをフラット化およびフラット化解除する機能があるため、おそらくValueInjectorです。

それで、これはやり過ぎですか？このアーキテクチャを使用しているシステムは非常に大規模です（すべてを書き直しています）。私はそれを正しくやっていますか？いつでもシステムの任意の部分を変更したいと思うことがあるので、すべてが依存関係に関してNinjectと切り離されています。考え、アイデア、批判は大歓迎です。

4

1 に答える 1

1

これは一般的なアーキテクチャであり、実際にはうまく機能します。中心的な利点の1つはカプセル化です。つまり、ドメインはサービスレイヤー（DDDのアプリケーションサービス）によってカプセル化されます。

WCFサービスに関しては、アダプターの方が適切な用語だと思います。これは、アプリケーションサービスレイヤーがコアであり、WCFがHTTP（またはその他のバインディング）をそれに適応させるヘキサゴナルアーキテクチャに基づいています。これを念頭に置いて、アプリケーションサービスはアダプタに依存しない方法で実装する必要があります。これは、WCF固有の属性またはデータコントラクトがないことを意味します。WCFアダプターは、アプリケーションサービスの周りの薄いレイヤーです。階層化が追加されたためにこのやり過ぎだと考える人もいるかもしれませんが、アプリケーション層にテクノロジー固有の懸念がないため、有益であることがわかりました。

このアーキテクチャがやり過ぎかどうかは、プロジェクトによって異なります。その質問に答える1つの方法は、アプリケーションがほとんどCRUDであるかどうかを判断することです。この場合、DDDは過剰であり、データベースからの読み取りとデータのサービスとしての直接公開を容易にするテクノロジーを使用する方がよい場合があります。

DDD内のサービスのより詳細な取り扱いについては、こちらをご覧ください。

于 2012-07-31T00:06:13.440 に答える