Martin Fowler は、ドメイン モデルと「データ ローダー」の間の境界としてサービス層を使用することを提案しています。ただし、Rockford Lhotka は、検証をビジネス オブジェクト自体に組み込むことを提案しており、これはまさに CSLA.NET が行っていることです。
これをサービス層に抽象化する利点は、明らかに、サービス層が複数のビジネス オブジェクト間でアクティビティ/操作を調整できることです。しかし、ビジネス ロジックと検証にビジネス オブジェクトを直接使用する場合と比較して、サービス レイヤーを使用する場合のその他の利点と欠点は何ですか?
あなたがこれを理解したかどうかはわかりません。
PEAAでのMartinFowlerの提案は、UI（またはクライアント）とドメイン/データレイヤーの間のAPIであるサービスレイヤーです。クライアントが使用できるすべての機能を公開します。
ドメインモデルを見ると（ここ）
動作とデータの両方を組み込んだドメインのオブジェクトモデル。
ドメイン層にはこれらのオブジェクトが含まれ、アクション/検証（動作）と状態（データ）が含まれます
これらのオブジェクトは他のアプリケーションで再利用できます。これは設計によっても異なります。ドメイン層はサービス層に依存してはなりません
したがって、ドメインオブジェクトには動作（検証を含む）とデータがあることを考慮してください。サービスレイヤーは、アプリケーションに公開させたいものです（機能的に実行するため）。IEは、顧客またはアカウントを追加して、月末の請求額を計算します。
シャープなアーキテクチャのレイアウトをご覧ください（http://www.sharparchitecture.net/）
これがこのメーターの私の理解です。
HTH
骨格
私は間違いなくロッキー・ロートカの陣営にいます。ビジネス オブジェクトは、アプリケーションと UI レイヤーの間で非常に簡単に "移植" できる必要があると思います。「サービスレイヤー」を追加すると、オブジェクトに依存関係が追加される可能性が高く、「移植性」が低下します。
ビジネス オブジェクト フレームワークを正しく記述すれば、ビジネス オブジェクトはさまざまなビジネス オブジェクト間の検証を正しく処理できるはずです。CSLA.NET は、親子関係と依存プロパティ検証の概念を持つことで、これを正しく行います。
データと動作が分離されている、より柔軟なドメインモデルを探していますが、サービスレイヤーが動作に適したレイヤーではないと思います。代わりに、おそらく、ビジネスエンティティオブジェクトがデータのみを公開し、ビジネスプロセスオブジェクトが動作のみを公開する単純なビジネスロジックレイヤーアプローチを採用することができます。これらの動作の中には検証メソッドがあります。
1つの利点は、ビジネスプロセスの結合がどれほど緩いかによって、検証をより広範囲の共変量、場合によっては不変のタイプに適用できることです。「FirstName」フィールドと「LastName」フィールドを検証することを少し考えてください。さらに、これらのフィールドは、大規模なシステムでは、半ダース以上の異なるエンティティに存在する可能性があることを考慮してください。プロセスをデータから分離することで、検証プロセスを一度実装して、同じデータを提供する多くのオブジェクトに適用できるようになります。
ドメインモデルが「データと動作の両方の融合であるドメインオブジェクトで構成される」という理想は、2000年から2002年頃のFowler / Evansの概念であることに気づきました（分散情報システムへの急速な移行の直後2層アプリケーションの代わりに。）
考え？