例如，我有一个用户表，要分层，我创建这样的 POJO：
UserEntity.java
UserDao.java
UserBO.java（业务对象、领域模型？）
UserService.java（用于服务层）
UserBO.java 和 UserService.java 有什么区别？为什么我们把它分成两个对象？
【问题讨论】：
标签： java business-objects service-layer domain-model
领域模型包含与成为用户的意义相关的信息和功能。它应该在概念上映射到现实世界中物理存在的事物或问题空间中明确定义的概念。
服务包含与执行原子工作单元相关的信息和功能。它应该在概念上映射到在域模型成员上或由域模型成员执行的任务。通过单击应用程序中的按钮执行的单个原子任务通常涉及域的许多成员一起工作，除非您的应用程序只是一个 CRUD-y 电子文件柜。
【讨论】：
实体：映射到问题域中某种实体（= 感兴趣的对象）的东西。在某些情况下（DDD），有丰富的域模型，其中实体具有可以操纵模型状态的方法。更保守的方法是让它们贫血（除了 getter 和 setter 之外没有其他方法）。通常，Entity 类最终会映射到数据库表。
BO：我猜这是某种数据传输对象。有些人非常担心将对实体的访问限制在应用程序的有限部分，他们喜欢将数据从实体复制到 DTO。因此，服务可能会从 DAO 接收实体，然后将其复制到 DTO 中，而 DTO 是服务调用者将返回的内容。
数据访问对象提供了一种查询或更新数据的方法，它可以具有返回实体或实体集合的查询方法。 DAO 通常不定义数据库事务，它们让服务来做。
服务是执行某些任务的东西，例如不同的用例通常不会沿着实体线清晰地分解。此外，服务通常涉及实体试图避免的依赖关系（因为域模型是关于建模状态和状态更改，而依赖关系是关于基础设施的）。服务可能具有为某些用户实现用例的方法，其中每个方法都是事务性的。
【讨论】：
也许概述的层次太高了，但这是我之前处理分层的方式，它与您的传统 N 层架构非常一致。
Web - 用户浏览器和您的服务层之间的接口，将 HTTP 参数转换为您的服务层需要的数据。
--- 使用业务对象在这些层之间进行通信---
服务 - 您的 Web 层和 DAO 层之间的接口，这里没有特定于传输协议的内容，即没有 HTTP 请求/参数，在您的情况下是业务对象。您所有的业务逻辑都驻留在此处。例如，如果您的 Web 层说“将权限 1 授予用户 1234”，那么您的服务层会将权限 1 转换为 READ 并将用户 1234 转换为在数据库中支持它的 UserEntity。
--- 使用实体在这些层之间进行通信---
DAO - 你的服务层和实际持久性机制之间的接口，应该尽可能地笨拙，这意味着如果“购买”对象上应该有一个“用户”对象，DAO 应该同时给出，它应该例如，不必处理查找用户。
使用层之间的这种分离可以轻松地进行单元测试和独立维护每一层。详细说明 BO，如果将数据从前端获取到封装在单个对象中的服务层，则最大的好处是将查找实际的 DB 条目留给服务层。希望对您有所帮助。
【讨论】：