我正在测试域驱动开发，但是需要一些指导，以在业务规则在聚合之外具有依赖项时如何实现业务规则。
我在Java中使用Spring Boot和JPA注释进行此操作。
好，简单的例子。假设我们有一个域对象集合： Car
汽车具有一个类别（以及此处未列出的许多其他相关实体）
类别是一个实体，是其自身的集合。该数据库包含所有可用和可接受的类别。有一个可用的CategoryRepository。类别包含自动生成的ID，唯一的categoryCode和描述。 categoryRepository允许您按categoryCode查找类别。
现在让我们考虑一个“简单”的业务规则。从汽车DTO更新汽车实体。 Car DTO包含新的汽车信息以及新的categoryCode。
所以我创建了一个Car.update（CarDTO）方法。该Car实体方法是一种更新方法，该方法将CarDTO作为输入，然后在Car实体上设置新值。
这是问题所在。 CarDTO包含categoryCode，而不是categoryId或category-entity。在Car对象中，我必须为category而不是categoryCode设置Category对象。 因此，那么Car对象必须依赖categoryRepository以便从类别代码解析正确的Category实体，或者我必须找到另一个解决方案。
如何解决业务规则具有依赖性的此类问题？
答案 0 :(得分：0)
如果您有实体/集合无法实现的代码，则应将此代码移至服务：
来自维基百科https://en.wikipedia.org/wiki/Domain-driven_design：
服务
当操作在概念上不属于任何对象时。 遵循问题的自然轮廓，您可以在服务中实施这些操作。
答案 1 :(得分：0)
您的问题陈述中可能存在误解。
首先，Spring和JPA与DDD无关。而且，我认为它们几乎是互斥的。 JPA实体与DDD实体不是同义词。第一个是数据库ORM技术，第二个是业务领域的某些部分（与“技术”完全相反）。
这也解释了您的业务规则的奇怪陈述：“从Car DTO更新Car实体”。我怀疑任何业务人员都会以这种方式制定需求，甚至在听到需求时也能理解需求。
“域驱动”的含义实际上是应用程序中的内容应使用业务语言。您的业务伙伴，用户或任何对您的用例足够熟悉的人所理解或知道的任何事物，都应该编入您的代码，仅此而已。
这也意味着，只有我们开发人员才能理解的技术知识应该隐藏在面向业务的类，方法名称和接口后面。
尝试以业务术语重述问题，专注于语言，注意对象而不是数据中的行为，问题可能会解决。为什么？因为如果可以以合理一致的方式陈述业务问题，那么您的代码应该会自动保持一致。如果不能，那么这不是技术问题。