跨越多个上下文的聚合答案

【问题标题】：Aggregate that spans multiple contexts跨越多个上下文的聚合
【发布时间】：2018-07-04 13:23:06
【问题描述】：

我正在尝试迁移一个没有任何架构规则的遗留系统，以遵守 DDD 原则。该系统涉及工资单和开票流程，因此我创建了工资单和计费 BC 以反映这些边界。

我遇到的问题可能是建模问题（DDD 还是新手，所以请耐心等待！）是在当前系统中有一个客户端页面。

其中包含一些一般详细信息、一些与工资单相关的信息以及一些与发票相关的信息。

这会是它自己的 BC，它拥有所有信息并通过事件传达工资单/发票相关信息，还是拥有一个共享内核和相关服务/存储库来管理客户？

采用这个简化模型：

{
    Id : 0,
    Name : "",
    Ref : "",
    BillingAddress : {
        //Address details for sending invoices to, should be in Invoicing BC
    },
    PayrollDetails : {
        //Details relating to payroll, should be in Payroll BC

    }
    //Some other properties that aren't relevant in invoicing or payroll

}

【问题讨论】：

看到这个：stackoverflow.com/a/42563610/2575224
里面有一个指向 :stackoverflow.com/questions/17916722/… 的链接会让一个 BC '拥有'客户端，而另一个存储对它的引用是一种可接受的方法吗？例如工资单 BC 将拥有客户，事件会将帐单详细信息与开票 BC 同步，但不会将帐单详细信息存储在工资单 BC 中？
这似乎让那个BC承担了太多责任。通过BC，您了解module（或您使用的任何模块化机制）？
每个 BC 应该只拥有它变异的数据。您可以拥有其他聚合数据的 BC，但只能以只读方式，即将它们呈现给用户或更快或更适合用例查询它们。
这个系统允许用户在创建时输入与两个 BC 相关的详细信息，所以想知道我将如何处理这个问题，这就是我在考虑客户端 BC 的地方向工资单和发票发出事件以同步相关信息

标签： architecture domain-driven-design

【解决方案1】：

这会是它自己的 BC，它拥有所有信息并通过事件传达工资单/发票相关信息，还是拥有一个共享内核和相关服务/存储库来管理客户？

您可能正在寻找组合式 UI 设计； Udi Dahan 多次写过关于这种模式的文章。

那么我会让控制器编排将所需的命令发送到不同的 BC 吗？

它可能是控制器，也可能是其他地方 - 取决于您喜欢分离关注点的积极程度以及您可以预期的重用程度。

这两个 BC 中都不需要的信息怎么样？

然后将该信息从其他地方的缓存中提取出来？

这些信息需要保存在某个地方，这就是为什么我问这是否意味着我有类似客户管理 BC 之类的东西？

客户关系管理 (CRM) 通常是它自己的上下文，有它自己的关注点，是的。

【讨论】：

那么我会让控制器编排将所需的命令发送到不同的 BC 吗？两个 BC 中都不需要的信息呢？
与任一 BC 无关的信息的意思是，例如，客户可能有联系方式，这不是工资单或发票所需的信息。这些信息需要保存在某个地方，这就是为什么我问这是否意味着我会有类似客户管理 BC 之类的东西？