0

I'm trying to implement data repositories based upon the aggregate roots. However, I'm not sure if this is the best way and I need your feedback.

Here are the aggregate roots of my system I've come up with (included are their childs indented below)

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

Plus more... the struggle I have is that, if proper data repositories are based upon aggregate roots, then technically should I have the Customer repository consume the Orders repository and instead of having two separate repositories for Customer and Order, instead we have Customer, with orders included in it

The only reason I have it separated is because of the large number of sub tables/items under the customer and order data repository.

I'm really interested in hearing how others would handle a situation like this when designing their data repositories and any other suggestions they might have for me.

Thanks in advance.

4

1 回答 1

2

如果不了解您的用例，就无法判断。

聚合根代表一个逻辑单元，可以在其上作为一个整体执行操作。

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

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

当然，关于 DDD 的开创性书籍是 Eric Evans 的“领域驱动设计”，它提供了大量的背景信息，当人们开始热衷于货物 DDD 时，这些背景通常会丢失。

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

当您拥有具有大量业务规则和行为/逻辑且未以实体状态编码的复杂域时，DDD 非常有用。大多数应用程序远比这简单得多，并且有更好的设计替代方案。

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

于 2013-03-08T16:06:44.733 回答