DDD：域间引用设计问题？

Question

DDD对域间引用设计的建议是什么？

我应该尝试将它们连接为“Matryoshka”（将其放入另一个），还是创建更高级别的“域间”业务服务更好？

P.S。穿过这片光滑的水，我无法在互联网上找到任何有用的东西，并开始认为这种东西比“域间引用”更好地存在......我是对的吗？

详情：

1. 我有两个模特/商业服务。
2. 语义上第一个域（A）是CRM，我们的商品有销售/维护过程，第二个域（B）是我们商品的“设计”数据。我们对商品有两个观点：从卖方角度和工程师角度。
3. 实际上每个模型都是对同一个数据库有效的ORM（对象 - 关系映射）工具。
4. 有一些域间活动，例如验证（例如，有时我们只能在某些工程规则有效的情况下将产品卖给smb。）。

从开发人员的角度来看，我有两个明确的可能性（A中的参考B或创建新的交叉引用域/服务C）。但是从设计师的角度来看，当我从两个不同的领域构建业务逻辑时，我很难理解我拥有什么样的业务服务。

Answer 1

据我所知，DDD没有严格的“域间”引用规则。在一天结束时，您的域模型必须引用基本的Java或.NET类。或者它可能引用专门的日期/时间或图形库（也称为“通用域”）。

另一方面，DDD的概念为Bounded Context。当你在系统的边界工作时，它有很多模式可以应用。例如，“反腐败层”可用于将您与旧系统隔离开来。可以使用其他集成样式，具体取决于您对外部代码，团队功能等的控制程度。

因此，如果您只在一个有界上下文中处理两个子域，则可能不需要引入人工胶层。可能还值得阅读DDD book（战略设计）的第4部分。

更新：

根据您提供的信息，您看起来只有一个有界上下文。你似乎没有“语言冲突”，因为同一个词有两个不同的含义。有界上下文集成模式很可能不适用于您的情况。您的销售域可以直接引用产品域。如果您认为Products域更低级别且Sales是高级别，您可以使用Dependency Inversion Principle。在Sales中定义类似ProductCompatiblityValidator的界面，并在Products域中实现它。然后在应用层注入实际的实现。这样，您就无法直接从销售到产品。

Answer 2

除了德米特里已经说过的话......

我认为任何跨越有界上下文的代码都是应用程序层代码。我会从两个上下文（及其存储库）中获得该应用程序层代码引用域类型，但不会有两个域相互引用。我认为，如果业务逻辑专门跨越域边界并且可以进行单元测试，那么在应用层中创建业务逻辑是可以的。

如果你真的有一个层次结构，那么可以让更具体的子域引用更抽象的域。但是，如果这导致您需要具有任何类型的域对象引用存储库，我会小心。从存储库中提取对象很少是真正的域概念。引用存储库最好在位于域模型上方的层中的应用程序层中完成。

当然，这与艺术一样多。我尝试用几种不同的方法对应用程序的一小部分进行建模，看看每种方法遇到的摩擦。