3

レイヤード パターンと DDD を使用しようとしています。しかし、単一のモデル エンティティの編集ビューで、コンボボックスとリストボックスに入力するために使用されるカタログをどこにロードすればよいかわかりません。ビューモデル ラッパーで、単一のビューに必要なすべてのリストを取得するために、アプリケーション サービス レイヤーに単一のメソッドを作成する必要がありますか? それとも、必要なリストごとに 1 つのメソッドを作成する必要がありますか? それとも、サービス層にまったく属していませんか?

4

1 に答える 1

9

プレゼンテーション レイヤーからデータにアクセスするには、主に 2 つの方法があり、いずれにも長所と短所があります。要約する：

1. アプリケーション サービス層の使用。

アプリケーション サービス レイヤーは、プレゼンテーション レイヤーから下のレイヤーへの API として機能します。これは、アプリケーション サービスが境界オブジェクトであることを意味します。アプリケーション サービスを介してエンティティと値オブジェクトを公開することはできますが、サービスとリポジトリはプレゼンテーション層から完全に隠されています。

利点:

  • レイヤー間の明確な分離を作成します。これにより、特にチーム内または複数のチームで作業する場合に、コードの開発、リファクタリング、保守、およびテストがいくらか容易になります。
  • アプリケーションの上に他のプレゼンテーションを構築する必要がある場合は、それを構築するための API が既にあります。
  • プレゼンテーション ロジックをアプリケーション ロジックから分離する場所があります。

短所:

  • 配線コード追加。ほとんどすべての作業を委任するメソッドを使用して、多くのサービスを作成する必要があります。正解するとこうなります。間違えると、ドメインモデルが貧弱になり、アプリケーションサービスが肥大化することになります。
  • 未知の目的に役立つ適切な API を作成することはほぼ不可能です。サービス呼び出しの適切な粒度は、その使用によってのみ決定できます。したがって、プレゼンテーションが 1 つしかない場合、アプリケーション サービスが変更なしで再利用可能であるという錯覚に陥ります。

私が見たサブ戦術は、アプリケーション サービスとドメイン サービスの両方がプレゼンテーション レイヤー内で使用されるというものです。たとえば、この記事を参照してください。アプリケーション サービスとドメイン サービスは根本的に異なるという著者の立場には同意しますが、プレゼンテーション レイヤー内から両方を使用できるようにする必要があるという点には同意しません。アプリケーション層を持つという目的は、アプリケーション サービスが境界として機能する場合に最もよく機能します。これにより、配線コードの量が増えますが、後の段階でアプリケーション ロジックを簡単に追加できます。したがって、この戦術を選択すると、すべてがうまくいくと私は主張します。

2. ドメイン層を直接使用する。

プレゼンテーション層内からリポジトリやサービスを呼び出すだけです。

利点:

  • 少ない配線コード。小さなコードベースで正確に何が起こっているかを簡単に確認できます。
  • ドメイン モデルがより多くの場所で使用されるようになり、外部の影響に対する耐性が高まります (優れたコーダーであれば、時間の経過と共に悪化するのではなく改善されます)。

短所:

  • 純粋なアプリケーション ロジックは、プレゼンテーション レイヤーに配置されます。別のプレゼンテーションを追加する必要がある場合は、そのロジックを複製するか、戦術 1 に戻る必要があります。
  • ドメイン モデルは同じ目標を達成する方法をいくつか提供する場合があるため、ロジックが重複するリスクがあります。重複コードは検出しやすく、防止するのが難しく、重複ロジックは検出しにくく、防止するのが簡単です。

別のサブ戦術私が実際に見たのは、ドメイン サービスがプレゼンテーション層への境界オブジェクトとして機能することです。したがって、リポジトリはプレゼンテーション層にアクセスできないと判断されます。アプリケーション ロジック、リポジトリ ロジック、およびドメイン ロジックは明らかに異なるタイプのロジックであるため、これをアンチパターンと呼びます (一部の人にとっては、これはあまり明確ではありません)。プレゼンテーション レイヤーのすべてのニーズをドメイン サービスで満たす必要がある場合、ドメイン サービスはリポジトリへのデリゲートになり (悪い)、アプリケーション ロジックがプレゼンテーション レイヤーに配置されるか (許容される場合があります)、またはアプリケーション ロジックが配置されます。ドメインサービスで（悪い）。DDD のドメイン サービスは、境界オブジェクトとしてではなく、エンティティまたは値オブジェクトの自然な部分ではないドメイン概念に関連する操作のコンテナーとしてのみ使用されます。また、

要約

このかなり複雑で多面的な議論を少し減らして、自分の用途に最も適した戦術を選択できることを願っています. これらのことについて、ソフトウェア業界には明確なコンセンサスがありません。私は通常、長寿命が保証されているか、いくつかのプレゼンテーションがあるソフトウェアに対して最初の戦術を選択し、将来がまだいくらか不確実で単一のプレゼンテーションがあるソフトウェアに対して2番目の戦術を選択します。

于 2013-10-16T10:35:27.077 に答える