Wo liegt die Logik zum Löschen abhängiger Objekte im domänenbasierten Design (DDD)?

Question

Wo gehört die Logik zum Löschen/Nicht-Löschen von abhängigen Objekten in DDD?

Zum Beispiel hat man eine Kategorie, die Produkte enthält:

class Category 
{ 
    IList<Products> products; 
} 

Eine Regel könnte sein, dass eine Kategorie nicht gelöscht werden kann, wenn es keine Produkte hat.

Wohin gehört die Logik, die vor dem Löschen nach Produkten dieser Kategorie sucht?

Domain-Klassen - Es scheint, Business-Logik zu sein, so würde ich vermuten, dass es in der Domain-Ebene gehören.

Repository-Klassen - Die Repository-Schicht behandelt Persistenz, hat die allgemeinen CRUD-Methoden, einschließlich einer zum Löschen, gehört die Logik in diese Schicht?

Eine andere Lösung?

Answer 1

Es ist wichtig, daran zu denken, dass DDD wie die meisten Ideen zum Softwaredesign eine Reihe von Richtlinien ist, keine harten und schnellen Regeln, also mach dir keine Sorgen darüber, ob du wirklich DDD machst . Wie bei den meisten Softwareszenarien lautet die Antwort: "Es kommt darauf an."

Verwenden Sie in diesem Szenario eine 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

Üblicherweise wird das Aggregat Wurzel wird Lebensdauer der Kinder Einheiten verwalten.