Best Aggregate Roots and Data Repositories Suggestions

Question

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.

Answer 1

It's impossible to tell without knowing your use cases.

Aggregate root represents a logical unit on which actions can be executed as a whole.

If the order can stand alone, that it should be an aggregate root. If it can't, then it shouldn't. E.g. LineItem makes no sense outside of order. However, order usually can be used without customer object - e.g. your shipping department can mark the order as shipped, regardless of customer, so typically it is an AR.

If you try to do DDD (for good or bad), then your design shouldn't be driven by underlying data technology and table layout. Who says you need to use an RDBMS?

The seminal book on DDD is, of course, Eric Evans' "Domain-driven design" which provides lots of context which usually gets lost when people start to cargo-cult DDD.

Jimmy Nilsson's "Applying Domain-Driven Design and Patterns" book is also frequently recommended, but I don't find it quite that good personally.

DDD is useful when you have complex domain with lots of business rules and behavior/logic which is not encoded in entity state. Most applications are far simpler than that and there are better design alternatives.

I suggest reading Martin Fowler's excellent book "Patterns of enterprise application architecture" - it covers wider area than DDD books and offers many good approaches for handling the application behavior, as well as covering all the application layers, from backend to GUI.