虽然我的 Java 应用程序很小而且做的事情很简单，但我很高兴使用纯 SQL，而且像 Glassfish 这样的应用程序服务器使连接管理变得非常容易。在了解了 JPA 和 EJB 之后，我决定重构我的项目，让它们使用这些很酷的东西，但遇到了一个更多关于设计而不是编程的问题：
将行为嵌入实体 Bean 是一种好习惯，还是它们应该只保存数据？
我已经阅读了许多手册和教程，但它们大多回答了我如何使用它们，而不是我应该如何使用它们来满足良好的设计要求。
例如，给定 2 个类：User和Location，它们都是实体 bean。Auser可以存储 s 的集合，location使用 JPA 实现起来也很方便。但是，如果我想用一些功能填充这些类，例如计算到另一个用户或位置的距离的方法，找到他们的路径交叉点，计算user一天跑过的距离等等。如果我在 bean 本身中实现这样的功能，或者我应该使用具有大量静态方法的特殊装饰器和辅助类来实现我的目标，这会是一个“好的设计”吗？
您正在尝试实施领域驱动 (DD) 方法。它对某些应用程序很有用，但往往与 SOA 架构相反。SOA 概念很普遍，经过高度验证，甚至是现在的热门话题，另请参阅微服务（又名 SOA v2.0）
如果您使用的是 Java EE，则可以使用网关模式为 SOA实现 DD 或边界控制实体。
现在几点：
将实体 Bean 用作普通对象，而不仅仅是作为数据表示，这是一种好习惯吗？对于 DD 来说，这没关系，也值得鼓励。对于 SOA，不是。
DD 设计是否会比 SOA 更好地扩展？取决于应用程序（有状态 bean 的内存占用很小且易于管理）。只有压力测试才能给你很好的洞察力。
我可以根据 DD 创建一个原型，然后在需要时传递给 SOA 吗？为什么不呢？，可能有一个硬重构阶段，但有可能。DD 原型的构建速度更快。
与不可变对象有关的任何安全问题值得一提吗？不可变对象旨在避免并发问题（无需更改，没有人受伤）。网关模式基于事务和 EJB（具有继承的安全模型）。所以总的来说，没有问题。
我需要使用 JPA 获取/设置吗？不，不是强制性的。
我可以使用 JPA 创建不可变对象吗？是的，只是一个构造函数和私有属性（正确注释）并完成。
我可以在 SOA 项目的实体中混合一些行为吗？好吧，我将只添加一些不需要向实体添加实体管理器的特定方法，这意味着，简单的操作不适用于庞大的对象图。整个项目的一致性非常重要。
测试呢？这两种解决方案都是高度可测试的。尽管 SOA 和微服务迫使您将应用程序分解成小块，这可能有助于您避免创建单体（大泥球）应用程序。
我讨厌地方性模型看起来多么糟糕，但至少可以。
我认为将所有这些逻辑方法放在您的实体上并不是一个好主意，也许最好的方法是从业务层获取它。
在我们的实体上获得大量瞬态字段永远不是一件好事，所以也许最好的方法是创建 VO（值对象）类。
使用 VO 也解决了封装问题，因为既不需要 setter，也不需要 getter。