所以我对将某些东西称为域对象（并最终将该类放在域包下）有疑问。
我有一个微服务，其职责是进行一些计算（不考虑实际的业务需求，它只是根据给定的请求计算一些intereset的回报）。现在为了实现计算，需要进行某些子计算，因此分别由不同的类组成。但是，是的，这些计算不需要在DB中持久化，也不需要ID（因此绝对不是实体或聚合）。然而，这些单独的计算器类（缺乏术语）确实包含一些复杂的业务逻辑。现在，我的问题是，这些单独的类仍然是资格/分类为域对象还是应该被称为服务？
如果需要，请随时询问有关用例的更多说明。
干杯！
答案 0 :(得分：4)
现在，我的问题是，这些单独的类是否仍然符合/分类为域对象，或者它们是否应被称为服务
从DDD的角度来看，在域层中，可以使用以下类来实现以下术语：Domain entities，Aggregate roots（Domain entity的类型），{ {1}}和Value objects。
由于您的内容没有Domain services，因此无法Identity或Domain entities。可以在Aggregate roots或Value objects内完成计算。 Domain services包含与值相关的特定行为，因此最有可能您的计算是使用Value objects 实现的。
根据我的经验，并非每个域类都必须是DDD构建块，它们可能只是为了更好的可维护性而提取的类，单一责任原则（一般是SOLID）等。
答案 1 :(得分：3)
一个简单的测试可能会问下面的问题 -
您的“计算器”（如您所述）是否将计算结果保存为不可变状态？ - 如果答案是肯定的，那么它就是一个价值对象。
“计算器”是否是无状态的，并且只暴露接受请求的“计算”行为＆amp;返回计算结果？ - 如果答案是肯定的，则它是服务，但是，此服务返回的“结果”可能被归类为值对象。
答案 2 :(得分：2)
我想说你的计算可以很好地适用于价值对象或域服务。
如何区分？好吧，我理解域服务是业务逻辑（例如你的计算）的服务（很明显），它需要注入一些外部依赖，以便让逻辑工作。
另一方面，如果您可以将业务逻辑命名为业务概念（即CustomerFee, CustomerCommission,等），并且您不需要任何注入的依赖项来使其工作，我会说它是一个价值对象。
例如，假设您想要计算预订的价格，这取决于您将向客户收取的费用（以及其他参数）：
ReservationPrice(CustomerFee customerFee, ItemPrice ItemPrice)
现在，您的CustomerFee也会根据（例如任何变量）计算出来。
通过这种方式，您只需使用Value Objects建模您的计算，它允许您在代码中显示它们所依赖的所有不同业务概念。任何查看代码和文件结构的人都可以了解您正在计算的内容。