Question

我正在尝试基于聚合根实现数据存储库。但是，我不确定这是否是最佳方式，我需要您的反馈。

以下是我提出的系统的集合根（包括他们的孩子在下面缩进）

Customer (Has Data Repository)
    CustomerAccount
    CustomerAccountPerson
    CustomerOptions
    CustomerCustomField
    CustomerCustomFieldData
    CustomerFile
    CustomerNote
    CustomerLoginLog
    ..... and more
Order (Has Data Repository)
    OrderLineItem
    OrderStatusLog
    OrderFlag
    OrderOutsourcing
    ..... and more
Lead (Has Data Repository)
    LeadNote
    LeadSource
    LeadStatus
    LeadStatusLog
    ..... and more
Invoice  (Has Data Repository)
    InvoiceOrder
    InvoicePayment

另外......我的斗争是，如果正确的数据存储库基于聚合根，那么从技术上讲，我应该让Customer存储库使用Orders存储库，而不是为Customer和Order提供两个单独的存储库，而不是我们有客户，其中包含订单

我将它分开的唯一原因是因为客户和订单数据存储库下存在大量子表/项。

我真的很想知道其他人在设计他们的数据存储库以及他们可能为我提出的任何其他建议时如何处理这种情况。

提前致谢。

Answer 1

如果不知道您的用例，就无法分辨。

聚合根表示可以作为整体执行操作的逻辑单元。

如果订单可以单独存在，那么它应该是聚合根。如果它不能，那么它不应该。例如。 LineItem在订单之外没有任何意义。但是，订单通常可以在没有客户对象的情况下使用无论客户如何，您的运输部门都可以将订单标记为已发货，因此通常是AR。

如果您尝试执行DDD（好的或坏的），那么您的设计不应该由底层数据技术和表格布局驱动。谁说您需要使用RDBMS？

关于DDD的开创性书籍当然是埃里克埃文斯的“领域驱动设计”，它提供了许多背景，当人们开始进行货物崇拜DDD时，这些背景通常会丢失。

Jimmy Nilsson的“应用领域驱动的设计和模式”一书也经常被推荐，但我个人并不觉得这么好。

当您拥有包含大量业务规则和行为/逻辑且未在实体状态下编码的复杂域时，DDD非常有用。大多数应用程序都比这简单得多，并且有更好的设计选择。

我建议阅读Martin Fowler的优秀书籍“企业应用程序架构模式” - 它涵盖了比DDD书籍更广泛的领域，并提供了许多处理应用程序行为的好方法，以及涵盖从后端到GUI的所有应用程序层。

最佳聚合根和数据存储库建议

1 个答案: