Question

我正在尝试移动一个没有任何建筑学科的遗留系统，遵守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

}

Answer 1

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

您可能正在寻找一个组合UI设计; Udi Dahan多次写过这种模式。

那么我是否让控制器协调将所需命令发送到不同的BC？

它可能是控制器，它可能在其他地方 - 取决于你喜欢分离问题的积极程度以及你可以期望的重复使用程度。

两个BC中并不真正需要的信息怎么样？

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

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

客户关系管理（CRM）通常是它自己的背景，有自己的担忧，是的。

跨越多个上下文的聚合

1 个答案: