ソフトウェア アーキテクチャにおけるドメイン オブジェクトとドメイン サービスとは何ですか? 私はそれらに精通していないか、ビジネスロジックレイヤーとどのように違うのですか?
4 に答える
さまざまな人々がこれらの用語を多少異なる方法で使用していますが、これが私の見解です。
1)「ビジネス」と「ドメイン」は大まかに同義語です。「ドメイン」は、ビジネスアプリケーションを作成していることを前提としないという点で、もう少し一般的です。したがって、科学的なアプリやゲームを作成している場合は、コードの関連部分を「ビジネス」コードではなく「ドメイン」コードと呼ぶ方がよいでしょう。したがって、この説明の残りの部分では、より一般的な「ドメイン」を使用します。
2)「ドメインロジック」は「ドメインオブジェクト」と「ドメインサービス」の両方を含みます。さまざまな理由(技術的およびその他)で、多くのアーキテクチャは、ドメインロジックがデータを格納するためのオブジェクト(「ドメインオブジェクト」)とそれらを操作するオブジェクト(「ドメインサービス」)に分割される設計を採用しています。Martin Fowlerらは、OOの概念の大部分は機能をデータと組み合わせることであるため、それはあまりOOではないと指摘しています。そうですが、それはまさにその通りです。ドメインオブジェクトはデータであり、ドメインサービスはデータを処理する部分です。
3)ドメイン駆動設計では、真のオブジェクト指向設計に戻るという考え方があります。そのため、さまざまなサービスメソッドがドメインオブジェクトに戻り、「貧血」と呼ばれることもあるオブジェクトではなく、オブジェクト指向の意味でオブジェクトを使用できるようになります。 "オブジェクト。DDDでは、ドメインオブジェクト自体がより堅牢であるため、ドメインロジックを形成します。実際には、まだいくつかのドメインサービスも存在する可能性がありますが、これは通常、従来のドメインオブジェクト対サービスモデルよりもDDDの方が小さくなります。
ビジネス ロジック層は、ドメイン層とも呼ばれます。これは、すべてのビジネス ロジックを処理するレイヤー/層です。
ドメイン オブジェクトとドメイン サービスは、ドメイン層を構築するために使用するクラスです。
違いを把握するには、アプリケーション層とドメイン (ビジネス) 層の役割を理解する必要があります。ドメイン レイヤーは、ビジネス オブジェクト、主にビジネスのエンティティ (ある程度抽象化されている可能性があります)、およびドメイン サービスを表します。ドメイン層は、ビジネスが変化したり、ビジネス内でドメインのコンテキストが変化した場合にのみ変更されます。アプリケーション層はドメイン層の上に「存在」し、多くの場合 (できれば) ドメイン層から分離されます。たとえば、コントローラー部分がアプリケーション層で HTML 部分がプレゼンテーション層である asp.net MVC Web アプリケーションのようにです。アプリケーション層は、その特定のアプリケーション (またはサービス、API、アプリなど) の目的に合わせて変更されます。
ドメイン層とビジネス層の両方にビジネス ロジックが含まれているのに異なる理由を説明するために、私が取り組んできたエンタープライズ アプリケーション シナリオの例を紹介します。
OMG CMMN 実装など、純粋なケース管理エンジンである COTS 製品があるとします。データ層の一連のエンティティと連携する、ビジネス層の一連のビジネス ロジック。
ここで、システム インテグレータである 2 人の顧客がいると仮定します。1 つは法務ケース管理システムを構築しており、もう 1 つは医療ケース管理を望んでいます。どちらもケース管理ですが、独自のドメイン用語、オブジェクト、手順、業界アーキテクチャなどがあります。
それぞれが独自のドメイン層を追加して、それぞれのビジネス ドメインの用語と概念で機能できるようにします。
はい、ビジネスロジックが含まれていますが、ドメイン層は、特定のビジネスで一般的な再利用可能なビジネスをカプセル化する方法です。
アプリケーションが「単純」であるほど、ドメイン モデルとデータ モデル、およびビジネス ロジックとドメイン ロジックが類似します。しかし、コンポーネントの発散の「有用性」を高めると、最終的には関心が分離されます。