Should aggregated roots have dependencies?

Question

In the book of Eric Evan's "Domain Driven Design" (which people often called "the best example for DDD") there are many examples of aggregate roots (mainly the domain models or objects), which is filled with a specific request.

Take the following example:

public Car : IAggregateRoot { public List<Wheel> Wheels { get; set; } public void ReplaceWheels(); } 

To replace the wheel, I have to request a new set of wheels from GarageService, who himself collects wheels WheelRepository. In one scenario, I am a customer and owner / mechanic garage, which replaces the wheel, so it is natural to call:

 myCar.ReplaceWheels(); // I'm a domain expert! I have the capabilities to replace the wheels 

My question: Is it right to enter WheelService dependent on the aggregate root? Or should I say only WheelService?

 public class MyCar : IAggregateRoot { private readonly IWheelService _wheelService; public List<Wheel> Wheels { get; set; } public MyCar(IWheelService wheelService) { this._wheelService = wheelService; } public void ReplaceWheels() { this.Wheels = _wheelService.getNewSet(); } } ; public class MyCar : IAggregateRoot { private readonly IWheelService _wheelService; public List<Wheel> Wheels { get; set; } public MyCar(IWheelService wheelService) { this._wheelService = wheelService; } public void ReplaceWheels() { this.Wheels = _wheelService.getNewSet(); } } 

or

 myWheelService.getNewSet(Car car); 

Answer 1

Aggregate roots, most likely, will be based. For example, if you have an aggregate root object Invoice, it will likely have a collection of LineItem. The only way to edit the position - to use InvoiceRepository.

If the invoice is not an aggregate root in the positions of the invoice will be its own repository.

Your example looks great if you never have to work with the wheels outside the vehicle context. The only question is, whether the vehicle can replace your wheels? If not, the method probably is not in the wrong place.