【问题标题】:DDD - Aggregates with large graphsDDD - 带有大图的聚合
【发布时间】:2014-11-06 05:12:34
【问题描述】:

我正在使用基于 DDD 的应用程序架构。我有以下情况。

我从另一个系统的 BizTalk Invoices 导入。这提供了我在应用程序内部反映的结构,如下图所示:

  • 订单 -> InvoiceHeader -> InvoiceHeaderDetails -> InvoiceDetails

通过繁重的后台计费流程,图表会增长并创建如下结构(现在它是最终模型):

  • BillingDoc -> 计费项目 -> 订单(每个计费项目)-> InvoiceHeader -> InvoiceHeaderDetail -> InvoiceDetails

最后,我需要在网格中使用这些 BillingDocs,并通过迭代大量 billingdocs 及其图表来了解 BillingDoc 是否具有 InvoiceHeader 和从外部系统导入的详细信息,这让我很担心。

鉴于我将迭代每个文档和大图,我如何在不影响性能的情况下将这些操作作为域模型的一部分进行。

如果在创建文档时它具有 InvoiceHeader,我所做的是标记聚合根。所以当我需要迭代时,我会避免挖掘大图。

对于如何改进该流程并保持我的域名正确,您有什么建议吗?你觉得我的解决方案怎么样?是否违反 ddd ?

非常感谢。

【问题讨论】:

  • 你只看订单吗?
  • 嘿 Jef,是的,一旦我执行了开票凭证之间的关系,我需要在网格中列出所有开票凭证并显示一个图标,其中显示有关导入订单的信息。但在网格中显示图标之前,我需要事先知道每个文档都包含导入的发票。所以这听起来像是一个性能问题。我正在研究如何做得更好。谢谢!!

标签: c# domain-driven-design n-tier-architecture


【解决方案1】:

如果您真正遵循 DDD,我认为您需要清楚地区分您的presentationObjects 和Domain Objects。如果您正在考虑将域对象暴露给 UI,那么我认为,这样的问题将会出现,并且从性能等方面来说真的很困难。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2016-06-28
    • 1970-01-01
    • 2017-05-25
    • 2016-03-21
    • 1970-01-01
    • 2020-10-19
    • 1970-01-01
    相关资源
    最近更新 更多