Should an aggregate root's behaviour be dependent on other aggregate root's attributes?

Question

I'm reading a book about DDD and i see an example domain that involves cars, engines, wheels and tires .

Above is the model as it is in the book . Customer is also aggregate root .
Having that model , there might be a case where the engine could have height, width and length attributes.
What happens when you need to attach a big engine on a small car ? The engine could not fit .
Is it a problem if the car checks for the engine attributes and allows it or not to be a part of the car ?
The engine has global identity (like you know each engine has a serial/manufacturer number). Maybe the engines need to be tracked by the manufacturer .

So I'm asking again , is it a problem if the car is using the engine's attributes to fit it inside (to allow it or not to be part of it) ?

Answer 1

Is it a problem if the car checks for the engine attributes and allows it or not to be a part of the car?

No.

That being said, your validation may be complex enough to introduce a domain service. Since two aggregates are involved you could have this:

car.Fit(engine)

Or this:

engine.Fit(car)

However, you probably want to be checking against a car model anyway :)

Since the rules are going to be somewhat more advanced and involve some data you probably want to introduce a domain service and possibly use double-dispatch on the objects:

So rather than car.Fit(engine) you could have this:

car.Fit(engine, IModelServiceImplementation)

And in the Fit method call:

if (!IModelServiceImplementation.CanFit(car, engine)) { throw new Exception(); }

The service could possibly load the correct model and rather check that against the engine. Depending on the domain one may even have modification levels and other rules to deal with.

Since a Car instance would not contain the actual Engine instance but only the EngineId or possibly some value object there would be no real assignment of engine to car. You could still pass the engine instance to the car and have it create the association however it sees fit.

The solution proposed by 'Enrico S.' is possibly more relevant to scenarios where changes are effected on the aggregate roots where one may not have all the aggregate roots available or even where aggregate roots live in separate bounded contexts. Even if Car and Engine were in separate BCs one would probably be able to query the validity somehow. Some things are fine for eventual consistency but others may not be.

As usual there are many things to consider :)

Answer 2

From DDD book, p128:

Any rule that spans AGGREGATES will not be expected to be up-to-date at all times. Through event processing, batch processing, or other update mechanisms, other dependencies can be resolved within some specific time.

So, it really depend on what Car aggregate is deigned for: if it requires strong consistency with the Engine, then the Engine should be part of the Car aggregate. Other way, if it require only "eventual consistency", you might put that validation logic inside a Domain Event.

See this Udi Dahan's post