以下是从 use case 中选择的三个业务对象
对于任何给定的用例，我的理解是，参与者 可以被视为业务对象，如果它属于以下两种情况:
- 如果该 actor 有自己的本地状态，并且该状态必须不时保持变化。
或者
- 如果该 actor 可能没有自己的本地状态，但通过关联(组合/聚合)影响另一个 actor 的状态。示例:
CoinFlipGameactor 影响 actorsPlayer和Coin。
要强调的是，我想概括一下，任何要被视为业务对象的 actor，该 actor 都应该属于上述两种情况。此外，每个业务对象都将是一个 OOP 类(C++/Java/C#)。
您是否同意这种在选择业务对象时派生 OOP 类的方法？
对于给定的用例，如何识别数据库中可以满足需求的业务对象？
最佳答案
请注意，一般来说，我们必须区分真实世界的对象(或业务对象)和 OOP 对象(例如 JS 对象或 Java 对象)。字符串可能是 OOP 对象(例如，在 Java 中)，但它不是业务对象。
在 Java 中，或者更具体地说，在 Java EE 中，实体 是一个特殊的 Java 对象，它实例化 Java 实体类，这是一个被 JPA 注释为 @Entity 的 Java 类，这样它的所有实例都会自动保存到 Java EE 环境(例如 TomEE)中的持久性存储中。
Java 实体旨在表示业务对象。 Java 字符串对象不能是 Java 实体。
任何(业务或 OOP)对象都有自己的(本地)状态，并且还可以访问通过引用(通过关联)链接到它的其他对象的状态。
问题是:域模型(例如玩家、预测、选项、硬币、硬币游戏)中的哪些业务对象类型必须包含为 OOP 类在面向对象的设计模型中？我们也可以说设计模型是从领域模型派生的，领域模型是从需求中获得的。
领域模型和设计模型都可以用 UML 类模型(可视化为类图)的形式制作，另请参阅 SO answer .域模型描述了真实世界的域，而 OO 设计模型定义了要使用特定 OOP 语言(如 Java)实现的 OOP 类。
从域模型中选择要包含在设计模型中的类取决于您的应用程序开发项目的信息要求。您必须确定您的模型(以及生成的 Java 类)要捕获的相关信息是什么。
如果您的应用的目的是记录和显示有关您的掷硬币游戏的信息，那么我会在设计模型中包含以下类:
- 玩家(id，名字)
- 游戏(id、日期时间、bettingPlayer、对手、赌注、结果)
这里，bettingPlayer和opponent是引用属性，代表Game和Player之间的对应关联。
从域模型进行这样的设计需要一些识别相关信息项的经验。将业务领域模型转换为 平台无关的系统设计模型涉及简化和细化。
域模型被简化为
- 从仅具有业务意义但对要构建的系统没有信息/计算意义的元素中抽象出来；
- 压缩模型的某些部分以获得更高效的设计(业务领域模型更关注概念的明确性，而系统设计模型更关注效率)
域模型是通过添加细节来详细说明的，这些细节对于设计来说是必不可少的(例如标准标识符、数据类型等)。
这是一个(不是最新的)tutorial这可能会提供一些帮助。
这是一个说明基于模型的开发过程的图表:
关于java - OO 设计 - 如何根据要求选择业务对象？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/46226783/