I'm looking at the evans example. Delivery history does query the handling events.

Fun fact, I implemented it using Ardalis:

https://github.com/renetitulaer/DDDShippingExample-Ardalis

Another example of a dependency would be logging.

Or in you example for contributor, check that there isn't already another contributor with the same name during construction (assuming that contributor name should be unique).

I saw the video and also read a bit more about DDD and the conclusion is that entities should not use dependencies. But that makes it hard to implement all the logic in the domain layer which should be the goal. For example the domain cannot check if it allowed to add a product with a serialnumber when that serial number already exists.
To solve this, we could introduce domain services. Application service are more process oriented, Domain service more entity related. A domain service communicated with the aggregate but is also able to collect data from other services. So the dependencies are in the domain service not in entity.

About factories, in the video, you gave a nice example when to use factories. Would it also make sense to use a factory method for destruction/delete?

Hello @renetitulaer 👋
Generally speaking I don't inject dependencies into my entities via constructor because I am using Entity Framework Core and that behavior isn't supported with constructor injection. Even if it was supported, I'm not sure I'd want an entity to take a dependency in it's constructor.

That being said, I do sometimes pass dependencies into methods on domain entities if I can't factor my code in another way.

For example the domain cannot check if it allowed to add a product with a serial number when that serial number already exists.

Ardalis does have a repo showing how to handle this no duplicate problem with a variety of solutions. I suggest checking it out as it demonstrates some good practices that also adhere to DDD practices.

https://github.com/ardalis/DDD-NoDuplicates

Hope this helps!