Java 服务层和领域模型层有什么区别
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/21339657/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
what's the difference between service layer and domain model layer
提问by lovespring
for example, I have a user table, to be layer-ing, I create such POJOs:
例如，我有一个用户表，要分层，我创建了这样的 POJO：
UserEntity.java
UserDao.java
UserBO.java (business object, domain model?)
UserService.java (for service layer)
UserEntity.java
UserDao.java
UserBO.java（业务对象，领域模型？）
UserService.java（服务层）
what's the difference between UserBO.java and UserService.java? why we seperate it to two objects?
UserBO.java 和 UserService.java 有什么区别？为什么我们把它分成两个对象？
采纳答案by Affe
The Domain Model contains information and functionality related to what it means to be a User. It should map conceptually onto something that exists physically in the real world or a clearly defined concept in the problem space.
域模型包含与成为用户意味着什么相关的信息和功能。它应该从概念上映射到现实世界中物理存在的事物或问题空间中明确定义的概念。
The Service contains information and functionality related to performing atomic units of work. It should map conceptually onto tasks that are performed on or by members of the Domain model. A single atomic task performed by clicking a button in the application generally involves many members of the Domain working together, unless you app is just a CRUD-y electronic filing cabinet.
该服务包含与执行原子工作单元相关的信息和功能。它应该在概念上映射到在域模型的成员上执行的任务或由域模型的成员执行的任务。通过单击应用程序中的按钮执行的单个原子任务通常涉及域的许多成员一起工作，除非您的应用程序只是一个 CRUD 式电子文件柜。
回答by Nathan Hughes
Entity: something that maps to some kind of entity (= object of interest) in the problem domain. In some cases (DDD) there are rich domain models where entities have methods that can manipulate the model's state. The more conservative approach is to make them anemic (no methods except getters and setters). Usually an Entity class ends up getting mapped to a database table.
实体：映射到问题域中某种实体（= 感兴趣的对象）的东西。在某些情况下 (DDD) 有丰富的域模型，其中实体具有可以操纵模型状态的方法。更保守的方法是让它们贫血（除了 getter 和 setter 之外没有其他方法）。通常，实体类最终会映射到数据库表。
BO: I'm guessing this is some kind of Data Transfer Object. Some people get very concerned about restricting access to entities to only a limited part of the application, and they like to copy data from entities into DTOs. So a service may receive an entity from a DAO, then copy that into a DTO and that DTO is what the service's caller would get back.
BO：我猜这是某种数据传输对象。有些人非常关心将实体访问限制在应用程序的有限部分，他们喜欢将数据从实体复制到 DTO。因此，服务可能会从 DAO 接收一个实体，然后将其复制到 DTO 中，而该 DTO 就是服务的调用者将返回的。
A Data Access Object provides a way to query or update data, it could have query methods that would return an entity or collection of entities. DAOs usually don't define database transactions, they let the service do that.
数据访问对象提供了一种查询或更新数据的方法，它可以具有返回实体或实体集合的查询方法。DAO 通常不定义数据库事务，它们让服务来完成。
A Service is something that performs some task, for instance the different use cases usually don't break down cleanly along entity lines. Also services usually involve dependencies that entities try to avoid (because the domain model is about modeling state and changes to state, and the dependencies are about infrastructure). A service may have methods that implement use cases for some user, where each method is transactional.
服务是执行某些任务的东西，例如不同的用例通常不会沿着实体线清晰地分解。此外，服务通常涉及实体试图避免的依赖项（因为域模型是关于建模状态和状态更改，而依赖项与基础设施有关）。服务可能具有为某些用户实现用例的方法，其中每个方法都是事务性的。
回答by SergeyB
Maybe too high level of an overview, but here is how I've approached layering before, it is pretty much in line with your traditional N-tier architecture.
也许概述的水平太高了，但这是我之前处理分层的方式，它非常符合您传统的 N 层架构。
Web - interface between user's browser and your service layer, converts HTTP params into data your service layer would need.
Web - 用户浏览器和您的服务层之间的接口，将 HTTP 参数转换为您的服务层需要的数据。
--- Use Business Objects to communicate between these layers ---
--- 使用业务对象在这些层之间进行通信 ---
Service - interface between your Web layer and your DAO layer, nothing specific to transmission protocols here, i.e. no HTTP requests/parameters, Business Objects in your case. All your business logic resides here. For example, if your web layer says "give permission 1 to user 1234", your service layer would convert permission one to READ and user 1234 to the UserEntity that backs it in the DB.
服务 - 您的 Web 层和 DAO 层之间的接口，这里没有特定于传输协议的内容，即没有 HTTP 请求/参数，在您的情况下是业务对象。您的所有业务逻辑都驻留在此处。例如，如果您的 web 层说“将权限 1 授予用户 1234”，则您的服务层会将权限 1 转换为 READ，将用户 1234 转换为在数据库中支持它的 UserEntity。
--- Use Entities to communicate between these layers ---
--- 使用实体在这些层之间进行通信 ---
DAO - interface between your Service layer and the actual persistence mechanism, should be as dumb as possible, meaning if "purchase" object is expected to have a "user" object on it, the DAO should be given both, it should not have to deal with looking up the user for example.
DAO - 你的服务层和实际持久化机制之间的接口，应该尽可能的愚蠢，这意味着如果“购买”对象上有一个“用户”对象，DAO 应该同时提供，它不应该例如处理查找用户。
Using this separation between layers makes it easy to unit test and maintain each layer independently of others. To elaborate on BO's, the biggest benefit of those if getting data from the front-end to the service layer encapsulated in a single object and it leaves looking up actual DB entries to the service layer. Hope it helps.
使用层之间的这种分离可以很容易地对每个层进行单元测试并独立于其他层进行维护。详细说明 BO 的最大好处是，如果将数据从前端获取到封装在单个对象中的服务层，并且将查找实际的 DB 条目留给服务层。希望能帮助到你。
