所以我对是否将某些东西称为域对象（并最终将类放在域包下）几乎没有疑问。
我有一个微服务，它的职责是进行一些计算（不涉及实际的业务需求，它所做的只是根据给定的请求计算一些兴趣集的回报）。现在为了实现计算，需要进行某些子计算，因此分别由不同的类组成。但是，是的，这些计算不需要保存在 DB 中，它们也没有 ID（所以绝对不是实体或聚合）。然而，这些单独的计算器类（由于缺乏术语）确实包含一些复杂的业务逻辑。现在，我的问题是，这些单独的类是否仍然有资格/归类为域对象，还是应该将它们称为服务？
如有需要，请随时询问有关用例的更多说明。
干杯！
【问题讨论】：
标签： domain-driven-design microservices business-logic
现在，我的问题是，这些单独的类是否仍然有资格/归类为域对象，还是应该将它们称为服务
从 DDD 的角度来看，在 Domain 层中，可以使用类来实现以下术语：Domain entities、Aggregate roots（Domain entity 的一种类型）、Value objects 和 Domain services .
因为您的事物没有Identity，它们不能是Domain entities 或Aggregate roots。可以在Value objects 或Domain services 内完成计算。 Value objects 包含与值相关的特定行为，因此很可能您的计算是使用 Domain services 实现的。
根据我的经验，并非每个域类都必须是 DDD 构建块，它们可能只是为了更好的可维护性、单一职责原则（一般为 SOLID）等而提取的类。
【讨论】：
Value Objects，因为在业务逻辑上，它们的行为会发生变化（读取多态实现）。但是，我目前的理解是值对象或多或少由Domain Object 本身组成，这反过来意味着我的Domain Object 将是一个（我试图实现的最终结果）。这种方法听起来不错？
Value objects 和Domain services。 Value object 更关心值、数据、状态及其对自己数据的行为（如金融领域中的 Money、数学中的点、身份验证中的用户名等），Domain objects 将行为应用于他们作为参数接收的输入数据.如果您可以描述您的域，也许我们可以确定最匹配的 DDD 模式类型。
Domain Services 绝对有意义，并且您的分类指南肯定会有所帮助，因此将其标记为答案。
一个简单的测试可能会问以下问题 -
您的“计算器”（如您所指）是否将计算结果保持为不可变状态？ — 如果答案是肯定的，那么它就是一个值对象。
“计算器”是无状态的，只公开接受请求并返回计算结果的“计算”行为吗？ — 如果答案是肯定的，那么它是一个服务，但是，这个服务返回的“结果”可能被归类为值对象。
【讨论】：
我会说您的计算可以很好地适应值对象或域服务。
如何区分？好吧，我将域服务理解为具有业务逻辑（例如您的计算）的服务（很明显），需要您注入某种外部依赖项才能使您的逻辑正常工作。
另一方面，如果您可以将该业务逻辑命名为业务概念（即CustomerFee,CustomerCommission, 等）并且您不需要任何注入的依赖项来使其工作，我会说它是一个值对象。
例如，假设您要计算预订价格，该价格取决于您将向客户收取的费用（以及其他参数）：
ReservationPrice(CustomerFee customerFee, ItemPrice ItemPrice)
现在您的CustomerFee 也是基于（比如说任何变量）某些东西计算出来的。
通过这种方式，您只需使用值对象对计算进行建模，这允许您在代码中显示它们所依赖的所有不同业务概念。此外，任何查看您的代码和文件结构的人都可以了解您正在计算的内容。
【讨论】：