的 DTO 和 VO 都应该被用来传输数据和没有嵌入逻辑。另一方面， 业务对象 应该嵌入一些逻辑。我说 一些
是因为，在用于协调涉及多个业务对象的逻辑的服务中所放置的服务与在业务对象本身中所放置的服务之间总能找到平衡。业务对象中的典型逻辑可以是验证，字段计算或一次仅影响一个业务对象的其他操作。
请注意，到目前为止，我还没有提到 实体 一词。持久性实体在ORM中得到了普及，如今，我们尝试将持久性实体同时用作DTO 和
业务对象。也就是说，实体本身在层和层之间流动，并包含一些逻辑。
还有其他更合理的理由不将逻辑放入我的实体中吗？还是要考虑其他任何问题？
正如您所指出的，这全都是依赖关系以及您公开的内容。只要实体是哑的（接近DTO），就可以轻松地将它们隔离在专用的jar中，用作 该层的API
。您在实体中放入的逻辑越多，执行此操作就越难。注意您公开的内容和所依赖的内容（加载类，客户端也需要具有依赖类）。这适用于异常，继承层次结构等。
仅举一个例子，我有一个项目，其中实体具有
toXml(...)用于业务层的方法。结果，实体的客户依赖于XML。
但是，如果您不太在乎层次以及API与实现之间的严格分隔，那么我认为最好在实体中移动一些逻辑。
编辑
由于没有明确的答案，这个问题已经讨论了很多次，并且可能会继续讨论。一些有趣的链接：
- 消气剂
- 贫血领域模型
- 封闭的重要性
- 领域建模
- 我的业务逻辑去哪儿了？
- 转移对象与业务对象
