3

The Law of Demeter is a rule that says that an object should only be aware of "closely related" other objects (my interpretation). See https://en.wikipedia.org/wiki/Law_of_Demeter.

The following examples do not follow the LoD:

// This class has to be aware of too many other classes, increasing complexity.
class Thing {
    void foo(Customer c, Employee e, System s, Company c, SupportTicket st) {
        // Th
    }
}

// This function likewise has to be aware of too many other classes.
void foo(SupportTicket st) {
    st.employee().division().incrementResolutionCount();
}

I am working on a system with a lot of complex relationships between data. In an SQL database, it'd be easy to perform a query with four different joins to get the data that I want. However, in such a scenario, you're loading an aggregate based off properties that it does not actually contain. If a Repository is an abstraction of an in-memory collection (i.e., a wrapper around an array in the simplest use case), then it's impossible for a purely in-memory collection to perform such a query, because no aggregates will ever match it.

The solution I've thought up is that you duplicate data between aggregates, not just between bounded contexts (http://www.infoq.com/news/2014/11/sharing-data-bounded-contexts). This increases conformance to the Law of Demeter, while allowing you to query aggregates based off properties that naturally "belong" to a related aggregate.

Is this approach recommended?

magnus
  • 4,031
  • 7
  • 26
  • 48

1 Answers1

11

Is this approach recommended?

Not by any authorities that I've seen.

The solution I've thought up is that you duplicate data between aggregates

What does that mean for your book of record?

The motivation for the domain model is to maintain the integrity of your book of record, ensuring that it always satisfies your business invariant. The aggregate boundaries describe disjoint regions within the domain that can be updated independently of each other - which is to say that each aggregate is sovereign over its own state.

So when you propose a design that duplicates data between two aggregates, what you are really asserting is that one fact in your book of record is really two different facts that may evolve independently of one another.

That might be silly, or that might be an important insight about the business. It's impossible to argue about generally; you'd have to sit down with your domain experts and hash it out.

I would, however, argue that a domain model which violates the Law of Demeter but actually describes the business correctly is vastly superior to an alternative design which satisfies the Law of Demeter but produces a misleading description of the business.

That said, it is reasonable to observe that your solution violates LoD, and on that basis push back on your requirements: sit down with your domain experts, explore the ubiquitous language, and get everybody onto the same page as to whether the business really is that complicated, and if it should be.

I am working on a system with a lot of complex relationships between data. In an SQL database, it'd be easy to perform a query with four different joins to get the data that I want. However, in such a scenario, you're loading an aggregate based off properties that it does not actually contain.

Why would you ever load an aggregate by anything but its identifier?

Hang on, did you say...

you're loading an aggregate based off properties that it does not actually contain.

You are trying to use a query that violates the Law of Demeter to load an aggregate? whistle yeah, somebody done be broken.

The CQRS pattern might be useful here, as a tool to help untangle what's really going on. Some immediate guesses

1) if you aren't trying to modify the state, you don't need an aggregate. Aggregates are used to enforce the business constraints on writes. If your use case is reading, then you want a read only representation of the state - aka a Projection.

2) If you are trying to modify the state, then you are processing a command, and command messages address a specific handler. It's really hard to think of a use case where you would be dispatching a command to an aggregate, without being able to identify that aggregate.

An alternative possibility is that the command you are considering is actually an event, with subscribers. Normally, the subscribers won't be aggregates in the domain model, but process managers that react to events by dispatching commands to aggregates.

3) There's still the possibility that you've drawn your aggregate boundaries in the wrong place.

VoiceOfUnreason
  • 52,766
  • 5
  • 49
  • 91