サービス層とドメインモデル層の違いは何ですか
たとえば、ユーザーテーブルがあり、レイヤー化するために、次のようなPOJOを作成します。
UserEntity.Java
UserDao.Java
UserBO.Java（ビジネスオブジェクト、ドメインモデル？）
UserService.Java（サービス層用）
userBO.JavaとUserService.javaの違いは何ですか？なぜそれを2つのオブジェクトに分離するのですか？
ドメインモデルには、ユーザーであることの意味に関連する情報と機能が含まれています。それは、現実の世界に物理的に存在するもの、または問題空間に明確に定義された概念に概念的にマッピングする必要があります。
本サービスには、アトミックな作業単位の実行に関連する情報と機能が含まれています。ドメインモデル上で、またはドメインモデルのメンバーによって実行されるタスクに概念的にマッピングする必要があります。アプリが単なるCRUD-y電子ファイリングキャビネットでない限り、アプリケーションのボタンをクリックして実行される単一のアトミックタスクには、通常、ドメインの多くのメンバーが協力して作業します。
エンティティ：問題のドメイン内のある種のエンティティ（=対象のオブジェクト）にマップするもの。場合によっては（DDD）、エンティティがモデルの状態を操作できるメソッドを持つリッチドメインモデルがあります。より保守的なアプローチは、それらを貧血にすることです（ゲッターとセッター以外の方法はありません）。通常、Entityクラスは最終的にデータベーステーブルにマップされます。
BO：これはある種のデータ転送オブジェクトだと思います。一部の人々は、エンティティへのアクセスをアプリケーションの限られた部分のみに制限することに非常に懸念を抱き、エンティティからDTOにデータをコピーすることを好みます。したがって、サービスはDAOからエンティティを受け取り、それをDTOにコピーすると、そのDTOがサービスの呼び出し元から返されます。
データアクセスオブジェクトは、データをクエリまたは更新する方法を提供します。エンティティまたはエンティティのコレクションを返すクエリメソッドを持つことができます。 DAOは通常、データベーストランザクションを定義せず、サービスに定義させます。
サービスは、いくつかのタスクを実行するものです。たとえば、さまざまなユースケースは通常、エンティティラインに沿って明確に分類されません。また、サービスには通常、エンティティが回避しようとする依存関係が含まれます（ドメインモデルは状態のモデリングと状態への変更に関するものであり、依存関係はインフラストラクチャに関するものであるため）。サービスには、各メソッドがトランザクションである、一部のユーザーのユースケースを実装するメソッドがある場合があります。
概要のレベルが高すぎるかもしれませんが、これは私が以前に階層化にアプローチした方法です。これは、従来のN層アーキテクチャとほぼ一致しています。
Web-ユーザーのブラウザとサービスレイヤー間のインターフェース。HTTPパラメータをサービスレイヤーが必要とするデータに変換します。
--- BusinessObjectsを使用してこれらのレイヤー間で通信します---
サービス-WebレイヤーとDAOレイヤーの間のインターフェース。ここでは送信プロトコルに固有のものはありません。つまり、HTTPリクエスト/パラメーターはなく、ビジネスオブジェクトもあります。すべてのビジネスロジックはここにあります。たとえば、Webレイヤーが「ユーザー1234にアクセス許可1を与える」と言っている場合、サービスレイヤーはアクセス許可1をREADに変換し、ユーザー1234をDBでそれをバックアップするUserEntityに変換します。
---エンティティを使用してこれらのレイヤー間で通信します---
DAO-サービスレイヤーと実際の永続化メカニズムの間のインターフェイスは、可能な限りダムにする必要があります。つまり、「購入」オブジェクトに「ユーザー」オブジェクトが含まれると予想される場合、DAOには両方を指定する必要があります。たとえば、ユーザーの検索を扱います。
このレイヤー間の分離を使用すると、各レイヤーを他のレイヤーから独立して単体テストおよび保守することが容易になります。 BOについて詳しく説明すると、フロントエンドからサービスレイヤーにデータを単一のオブジェクトにカプセル化して取得し、実際のDBエントリをサービスレイヤーに検索する場合の最大のメリットです。それが役に立てば幸い。