2

約1年前、ASP.Net MVC 3（現在）のプレゼンテーション層、アプリケーション層、ドメイン層、インフラストラクチャ層（横断的なものとデータ）で構成されるソリューションをセットアップしました。現在、フロントエンドは1つしかないため、ドメインモデルをドメインロジックとは別のプロジェクトに保持し、DTOの代わりにドメインエンティティを渡すことで、プレゼンテーション層へのリラックスしたアプローチを使用することにしました。

メインのWebサイトに加えて、まもなく分散レイヤーのサービスを提供する予定であり、そこでDTOを使用しますが、メインのWebサイトでもDTOを使用することを検討しています。また、ドメインレイヤー（IRepository、IUnitOfWork、Entity / Valueオブジェクトのスーパータイプなど）でフレームワークコードをわざわざ分割する必要があるかどうかも疑問に思っています。ここで、フィードバックが必要な質問をリストアップしましょう。

1）貧血のドメインモデルを持たないことにかなり熱心に取り組み、プレゼンテーションの懸念に固有の動作にも注意しました。必要なビジネス計算のほとんどはドメインエンティティで行われます。プレゼンテーション層がこの動作を直接呼び出すことは問題ありませんか、それとも代わりにアプリケーションサービスを呼び出してドメインエンティティを呼び出す必要がありますか？これは、プレゼンテーション層にドメインエンティティについて認識させる理由がなく、代わりにDTOを使用できることを示唆しています。または、DTOにこれらの動作を公開させることもできますが、ドメインエンティティを奪っているような気がします。だから私はそれが最良の3つのオプション（直接呼び出されるリッチドメインオブジェクト、サービスレイヤーまたは動作付きのdto）だと思いますか？

2）現在、ドメインサービス、仕様、ロジックを備え、アプリケーション層とドメインモデル用の個別のプロジェクト（プレゼンテーション層とアプリケーション層で使用）によって調整されたドメインプロジェクトがあります。ここには、ジェネリックリポジトリと作業単位パターンのフレームワークインターフェイスもあります。フレームワークのものを別のプロジェクトに分割し、残りを1つのプロジェクトに結合する必要がありますか？

3）ドメインレイヤーを集約に再編成したいのですが、現在、すべてのドメインモデルはモジュールごとに編成されており、基本的に各モジュールのすべてのタイプが1つの名前空間にあります。エンティティ、値オブジェクト、サービス、その他のものを集計ごとに整理する方がよいでしょうか？

4）基本的に.net Frameworkヘルパーライブラリタイプであるインフラストラクチャサービスに分離インターフェイスパターンを使用する必要がありますか？たとえば、構成オブジェクトまたは検証ランナー？そうすることの利点は何ですか？

5）最後に、私が見た例の多くは、ドメインエンティティのインターフェイスを使用していません。私が持っているほとんどすべてのオブジェクトは、依存関係の理由でインターフェースを渡すことを好み、テストがはるかに簡単になります。コンクリートの代わりにインターフェースを使用することは有効ですか？EF 4.3.1（まもなく最新バージョンにアップグレードする）を使用していることを言及する必要があります。EFにはインターフェイスなどの使用に問題があったことを覚えているようです。ドメインエンティティの代わりにインターフェイスを公開する必要がありますか？

事前にどうもありがとうございました。

プロジェクト構造：

Presentation.Web
     | |
     | 応用
     | | |
Domain.Model-ドメイン

（Infrastructure.Data、Infrastructure.Core、Infrastructure.Security）

説明：Presentation.Web（MVC3 Webプロジェクト）

アプリケーション-ドメイン層を調整し、プレゼンテーション層からの要求に応答するサービス層（この更新を取得します）。これはモジュールごとに編成されています。たとえば、顧客モジュールがある場合はApplication.Customerがあり、その中にすべてのアプリケーションサービスがあります。

ドメイン-ドメインエンティティの動作として公開されていないドメインサービス、仕様、計算、およびその他のドメインロジックが含まれます。たとえば、アプリケーション層が呼び出すドメインサービスとして公開されている複数のドメインエンティティを含む計算。-仕様フレームワークのフレームワークコードと、汎用リポジトリおよび作業単位パターンのメインインターフェイスも含まれています。

Domain.Model-ドメインエンティティと列挙が含まれます。モジュールごとに整理されています。たとえば、customerエンティティ、customerorderエンティティなどを含むcustomerモジュールがある場合、これはドメインプロジェクトから切り離され、アプリケーションとプレゼンテーションレイヤーでオブジェクトを使用できるようになります。

Infrastructure.Security-認証と承認のためのセキュリティインフラストラクチャ

Infrastructure.Core-複数のレイヤー（バリデーター、ロギング、構成、拡張機能、IoC、電子メールなど）で使用される分野横断的なもの。ほとんどのプロジェクトは、インフラストラクチャサービスをこのプロジェクトのインターフェイス（domain.modelを除く）に依存しています。

Infrastructure.Data-LINQおよびEF4.3.1を介したリポジトリの実装、マッピングレイヤー、作業単位の実装。インターフェイスはドメインプロジェクトにあります（分離されたインターフェイスパターン）

4

1 に答える 1

1

1）まず、メインのWebサイトが本当にアプリケーション層を使用する必要があるかどうかを判断します。IMHO、アプリケーションサービスとメインWebサイトが同じWebサーバー上にある場合、ドメインオブジェクトを直接呼び出すことができるときに、メインWebサイトがアプリサーバーメソッドを呼び出す価値があるかどうかを評価する必要があります。ただし、アプリケーションサーバーが確実に別のサーバー上にある場合は、そうです。アプリケーションサーバーでドメインオブジェクトを呼び出し、メインWebサイトを含むプレゼンテーションレイヤーとの間でDTOのみをやり取りする必要があります。

2）これは本当に組織の好みに関する質問です。どちらも有効です。選んで。

3）組織の選好に関する異議申し立て。私は個人的に、最初に制限されたコンテキストでコードを整理します。次に、エンティティがあり、その直下にルートを集約します。次に、列挙、リポジトリ（インターフェイス）、サービス（インターフェイス）、仕様、および値のフォルダがあります。名前空間は、最後に制限されたコンテキストフォルダーを超えたこの組織構造を反映していません。ただし、繰り返しになりますが、コードの見方に最も適した方法でこれを行う必要があります。

4）これは実装上の懸念事項です。私は個人的に、将来実装を交換する必要がある可能性が高いと思う場合にのみ、実装の懸念をインターフェースに分解します。そうは言っても、私は通常、ヘルパーライブラリを特定のインフラストラクチャコンテキスト（例：MainContext.Web.MVC.HelpersまたはMainContext.Web.WebForms.Helpers）に編成します。これらはめったに変更されず、必要なインスタンスにまだ遭遇していません。実装を完全に交換します。

5）私の理解では、ドメインエンティティに具象の代わりにインターフェースを使用することは完全に有効です。そうは言っても、ドメインエンティティに異なる実装が必要な場合はまだ発生していません。私が考えることができる唯一の理由は、1つのアプリケーションのビジネスロジックを変更する必要があるが、元のビジネスロジックを使用して古いアプリケーションを残す必要がある場合です。あなたのビジネスオブジェクトがドメインの良いモデルである場合、私はあなたが実際にこの問題に遭遇しているとは推測できませんが、抽象化のためだけに人々がこれを行う例を見てきました。IMHO、それは余分なコーディング努力の価値はありませんが、それがあなたが内部で気分が良くなるか、実際の利益を得る（例えば、テストを容易にする）場合、ドメインエンティティを抽象化できない理由はありません。そうは言っても、

回答5は、アプリケーションが実装を選択するものであるという考えから導き出されています。タマネギアーキテクチャを実現しようとしている場合、アプリケーションはすべての具体的な実装（リポジトリ、ドメインサービス、およびその他の抽象化された実装の懸念事項）を選択することになります。ドメインアグリゲートはドメインモデルの具体的な表現であるため、ドメインアグリゲートを直接使用できない理由はわかりません。（注：すべてのエンティティはアグリゲートにカプセル化する必要があります。アプリケーションは、コンテキストの下でアグリゲートではないエンティティへの参照を保持できないようにする必要があります）

于 2012-12-14T21:23:39.487 に答える