Architecture 跨多个上下文的聚合

我试图移动一个没有任何体系结构规则的遗留系统，以遵守DDD原则。该系统涉及工资单和发票流程，因此我创建了工资单和账单业务连续性，以反映这些边界

我的问题是，在当前系统中有一个客户端页面，这可能是一个建模问题（对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

}

这是它自己的BC，它保存所有信息并通过事件传递与工资单/发票相关的信息，还是有一个用于管理客户机的共享内核和相关服务/存储库

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

---

那么，我会让控制器协调将所需的命令发送到不同的BC吗

它可能是控制器，也可能是其他地方——这取决于您希望分离关注点的积极程度以及您可以期望的重用程度

两个BCs中都不需要的信息如何

然后从其他地方的缓存中提取信息

这些信息需要保存在某个地方，这就是为什么我问这是否意味着我会有类似于客户管理业务连续性的东西

---

客户关系管理（CRM）通常是它自己的环境，有它自己的关注点，是的。

看到这一点：其中有一个链接：一个BC“拥有”客户，另一个BC存储对客户的引用是一种可接受的方法吗？e、 g.工资单业务连续性将拥有客户，事件将账单明细与发票业务连续性同步，但不将账单明细存储在工资单业务连续性中？这似乎让该业务连续性承担了太多的责任。通过

BC

您可以理解

module

（或者您使用的任何模块化机制）？每个BC应该只拥有其变异的数据。您可以使用其他BC来聚合数据，但只能以只读方式，即向用户呈现数据或更快或更适合于某个用例的查询数据。此时的系统允许用户在创建时输入与两个BC相关的详细信息，因此我想知道如何处理这些信息，这就是我想到的客户业务连续性，它将向工资单和发票发送事件，以同步相关信息，因此我是否会让控制器协调向不同的业务连续性发送所需的命令？这两个业务连续性系统中都不需要的信息如何？与这两个业务连续性系统无关的信息的意思是，例如，客户可能有联系方式，这不是工资单或发票所需的信息。这些信息需要保存在某个地方，这就是为什么我问这是否意味着我会有类似于客户管理业务连续性的东西？