Wzór specyfikacji w Domain Driven Design

Kiedyś zaimplementowałem specyfikację, ale...

Bazował na LINQ i IQueryable.
1. używało pojedynczego, zunifikowanego repozytorium (ale jak dla mnie nie jest źle i myślę, że to główny powód do używania specyfikacji).
2. używał jednego modelu dla domeny i stałych potrzeb (co uważam za złe).

Repozytorium:

public interface IRepository<TEntity> where TEntity : Entity, IAggregateRoot
{
    TEntity Get<TKey>(TKey id);

    TEntity TryGet<TKey>(TKey id);

    void DeleteByKey<TKey>(TKey id);

    void Delete(TEntity entity);

    void Delete(IEnumerable<TEntity> entities);

    IEnumerable<TEntity> List(FilterSpecification<TEntity> specification);

    TEntity Single(FilterSpecification<TEntity> specification);        

    TEntity First(FilterSpecification<TEntity> specification);

    TResult Compute<TResult>(ComputationSpecification<TEntity, TResult> specification);

    IEnumerable<TEntity> ListAll();

    //and some other methods
}

Specyfikacja filtra:

public abstract class FilterSpecification<TAggregateRoot> where TAggregateRoot : Entity, IAggregateRoot
{

     public abstract IQueryable<TAggregateRoot> Filter(IQueryable<TAggregateRoot> aggregateRoots);

     public static FilterSpecification<TAggregateRoot> CreateByPredicate(Expression<Func<TAggregateRoot, bool>> predicate)
     {
         return new PredicateFilterSpecification<TAggregateRoot>(predicate);
     }      

     public static FilterSpecification<TAggregateRoot> operator &(FilterSpecification<TAggregateRoot> op1, FilterSpecification<TAggregateRoot> op2)
     {
         return new CompositeFilterSpecification<TAggregateRoot>(op1, op2);
     }        

     public static FilterSpecification<TAggregateRoot> CreateDummy()
     {
         return new DummyFilterSpecification<TAggregateRoot>();
     }

}


public class CompositeFilterSpecification<TAggregateRoot> : FilterSpecification<TAggregateRoot> where TAggregateRoot : Entity, IAggregateRoot
{

    private readonly FilterSpecification<TAggregateRoot> _firstOperand;
    private readonly FilterSpecification<TAggregateRoot> _secondOperand;

    public CompositeFilterSpecification(FilterSpecification<TAggregateRoot> firstOperand, FilterSpecification<TAggregateRoot> secondOperand)
    {
        _firstOperand = firstOperand;
        _secondOperand = secondOperand;
    }

    public override IQueryable<TAggregateRoot> Filter(IQueryable<TAggregateRoot> aggregateRoots)
    {
        var operand1Results = _firstOperand.Filter(aggregateRoots);
        return _secondOperand.Filter(operand1Results);
    }
}

public class PredicateFilterSpecification<TAggregateRoot> : FilterSpecification<TAggregateRoot> where TAggregateRoot : Entity, IAggregateRoot
{

    private readonly Expression<Func<TAggregateRoot, bool>> _predicate;

    public PredicateFilterSpecification(Expression<Func<TAggregateRoot, bool>> predicate)
    {
        _predicate = predicate;
    }

    public override IQueryable<TAggregateRoot> Filter(IQueryable<TAggregateRoot> aggregateRoots)
    {
        return aggregateRoots.Where(_predicate);
    }
}

Inny rodzaj specyfikacji:

public abstract class ComputationSpecification<TAggregateRoot, TResult> where TAggregateRoot : Entity, IAggregateRoot
{

    public abstract TResult Compute(IQueryable<TAggregateRoot> aggregateRoots);

    public static CompositeComputationSpecification<TAggregateRoot, TResult> operator &(FilterSpecification<TAggregateRoot> op1, ComputationSpecification<TAggregateRoot, TResult> op2)
    {
        return new CompositeComputationSpecification<TAggregateRoot, TResult>(op1, op2);
    }

}

I zastosowania:

OrderRepository.Compute(new MaxInvoiceNumberComputationSpecification()) + 1
PlaceRepository.Single(FilterSpecification<Place>.CreateByPredicate(p => p.Name == placeName));
UnitRepository.Compute(new UnitsAreAvailableForPickingFilterSpecification() & new CheckStockContainsEnoughUnitsOfGivenProductComputatonSpecification(count, product));

Custom implementacje mogą wyglądać tak:

public class CheckUnitsOfGivenProductExistOnPlaceComputationSpecification : ComputationSpecification<Unit, bool>
{
    private readonly Product _product;
    private readonly Place _place;

    public CheckUnitsOfGivenProductExistOnPlaceComputationSpecification(
        Place place,
        Product product)
    {
        _place = place;
        _product = product;
    }

    public override bool Compute(IQueryable<Unit> aggregateRoots)
    {
        return aggregateRoots.Any(unit => unit.Product == _product && unit.Place == _place);
    }
}

Wreszcie, jestem zmuszony powiedzieć, że prosta Specficiation implementacja źle pasuje do DDD. Zrobiłeś świetne badania w tej dziedzinie i jest mało prawdopodobne, że ktoś zaproponuje coś nowego :). Zobacz też: http://www.sapiensworks.com/blog / blog.

[[2]] szukałem od tygodni w całym Internecie, przeczytałem dziesiątki artykuły na temat DDD i specyfikacji, ale zawsze obsługują tylko proste przypadków i nie biorą pod uwagę wydajności lub ich naruszać wzorzec DDD.

Ktoś mnie poprawi, jeśli się mylę, ale wydaje mi się, że pojęcie "modelu Persistence" pojawiło się dopiero niedawno w przestrzeni DDD (swoją drogą, gdzie o tym czytałeś ?). Nie jestem pewien, czy jest to opisane w oryginalna niebieska Księga.

Teraz jest podejście CQRS, gdzie masz oddzielny model odczytu, ale jest to zupełnie inne zwierzę i nie widzę Specifications działania na obiektach modelu odczytu zamiast encji jako naruszenia DDD w tym przypadku. Specyfikacja jest wszakże bardzo ogólnym wzorcem, którego nic w DDD zasadniczo nie ogranicza do Bytów.

(*) Edit : twórca Automapp Jimmy Bogard wydaje się być zbyt skomplikowany - Zobacz Jak używać automapp do mapowania wielu do wielu związki?

Spóźnię się na imprezę, bug tu są moje 2 centy...

Zmagałem się również z implementacją wzoru specyfikacji z dokładnie tych samych powodów, które opisałeś powyżej. Jeśli zrezygnujesz z wymogu oddzielnego modelu (trwałość / domena), twój problem zostanie znacznie uproszczony. możesz dodać inną metodę do specyfikacji, aby wygenerować drzewo wyrażeń dla ORM:

public interface ISpecification<T>
{
    bool IsSpecifiedBy(T item);
    Expression<Func<T, bool>> GetPredicate()
}

Jest post z Valdmira Khorikova opisujący jak to zrobić w szczegóły.

Jednakże, naprawdę nie lubię mieć jednego modelu . Podobnie jak ty uważam, że model Perystencji powinien być utrzymywany w warstwie infrastruktury, aby nie zanieczyszczać Twojej domeny z powodu ograniczeń ORM.

W końcu wymyśliłem rozwiązanie, używając gościa, aby przetłumaczyć model domeny na drzewo wyrażeń modelu persistence.

Ostatnio napisałem serię postów, w których wyjaśniam

• Jak stworzyć specyfikację generyczną w C #
• Co to jest Visitor Design Pattern i jak uczynić go ogólnym.
• i moje podejście do tego, jak zaimplementować wzorzec specyfikacji w entity framework

Efekt końcowy staje się bardzo prosty w rzeczywistości, musisz zrobić specyfikację Visitable...

public interface IProductSpecification
{
    bool IsSpecifiedBy(Product item);
    TResult Accept(IProductSpecificationVisitor<TResult> visitor);
}

Utwórz SpecificationVisitor aby przetłumaczyć specyfikację na wyrażenie:

public class ProductEFExpressionVisitor : IProductSpecificationVisitor<Expression<Func<EFProduct, bool>>> 
{
    public Expression<Func<EFProduct, bool>>Visit (ProductMatchesCategory spec) 
    {
        var categoryName = spec.Category.CategoryName;
        return ef => ef.Category == categoryName;
    }

    //other specification-specific visit methods
}

Jest tylko tweeking, który trzeba zrobić, jeśli chcesz stworzyć ogólne spefication. Jego wszystkie szczegółowe w postach wymienionych powyżej.