Where is the Reisde logic for deleting dependent objects in domain design (DDD)?

Question

Where does the logic for deleting / not deleting dependent objects belong to DDD?

For example, you have a category containing products:

class Category { IList<Products> products; } 

A rule may be that you cannot delete a category if it does not have products.

Where is the logic that checks for the absence of products in this category before uninstalling?

• Domain classes. This is apparently business logic, so I would suggest that it belongs to the domain layer.
• Repository classes. The repository level handles persistence, it has common CRUD methods, including one for deletion, does the logic contain in this layer?
• Another solution?

Answer 1

It’s important to remember that, like most software development ideas, DDD is a set of guidelines, not hard and fast rules, so don’t worry if what you are doing is really a DDD. Like most software scripts, the answer is "It depends."

In this case, consider using Specification .

 Category category; // some category you're working with. ICategoryRepository _categoryRepository; // some repository. ISpecification readyForRemoval = new ReadyForRemovalSpecification(); if (readyForRemoval.IsSatisfiedBy(category) { _categoryRepository.Remove(category); } public class ReadyForRemovalSpecification : ISpecification<Category> { public bool IsSatisfiedBy(Category category) { return (category.HasProducts == false); // return category.Products.Count = 0; // whatever... } } 

Answer 2

Typically, the cumulative root will control the lifetime of child objects.