I've been struggling around an DDD related issue with Specifications and I've read much into DDD and specifications and repositories.
However, there is an issue if trying to combine all 3 of these without breaking the domain driven design. It boils down to how to apply filters with performance in mind.
First a few obvious facts:
So far, so easy. The problem arises when/if we try to apply Specifications to the Repository and not breaking DDD pattern or having performance issues.
The possible ways to apply Specifications:
1) Classic way: Specifications using Domain Model in Domain Layer
Apply the traditional Specification Pattern, with a IsSatisfiedBy
method, returning a bool
and Composite Specifications to combine multiple Specifications.
This let us keep specifications in Domain Layer, but...
AutoMapper
. 2) Specifications using Persistence Model
This is similar to 1), but using Persistence Models in the specification. This allows direct use of the Specification as part of our .Where
predicate which will be translated into a query (i.e. TSQL) and the filtering will be performed on the Persistence storage (i.e. SQL Server).
3) Like 2), but make Specifications Part of the Persistence Layer
4) Like 3, but use abstract the Specifications as Interfaces
We would have Specification interfaces in our Domain layer, our concrete implementations of the Specifications in the Persistence Layer. Now our Domain Layer would only interact with the interfaces and not depend on the Persistence layer.
5) Translate the Expression Tree from Domain Model into Persistence Model
This certainly solves the problem, but it's non-trivial task but it would keep the Specifications inside our Domain Layer while still benefiting from SQL optimization, because the Specifications becomes part of the Repositories Where clause and translates into TSQL
I tried going this approach and there are several issues (form implementation side):
6) Query Builder like API
The last one is making some kind of query API which is passed into the specification and from whom the Repository/Persistence layer would generate an Expression Tree to be passed to .Where
clause and which uses an Interface to declare all filterable fields.
I did a few attempts in that direction too, but wasn't too happy about the results. Something like
public interface IQuery<T>
{
IQuery<T> Where(Expression<Func<T, T>> predicate);
}
public interface IQueryFilter<TFilter>
{
TFilter And(TFilter other);
TFilter Or(TFilter other);
TFilter Not(TFilter other);
}
public interface IQueryField<TSource, IQueryFilter>
{
IQueryFilter Equal(TSource other);
IQueryFilter GreaterThan(TSource other);
IQueryFilter Greater(TSource other);
IQueryFilter LesserThan(TSource other);
IQueryFilter Lesser(TSource other);
}
public interface IPersonQueryFilter : IQueryFilter<IPersonQueryFilter>
{
IQueryField<int, IPersonQueryFilter> ID { get; }
IQueryField<string, IPersonQueryFilter> Name { get; }
IQueryField<int, IPersonQueryFilter> Age { get; }
}
and in the specification we would pass a IQuery<IPersonQueryFilter> query
to the specifications constructor and then apply the specifications to it when using or combining it.
IQuery<IGridQueryFilter> query = null;
query.Where(f => f.Name.Equal("Bob") );
I don't like this approach much, as it makes handling complex specifications somewhat hard (like and or if chaining) and I don't like the way the And/Or/Not would work, especially creating expression trees from this "API".
I have been looking for weeks all over the Internet, read dozens of articles on DDD and Specification, but they always only handle simple cases and don't take the performance into consideration or they violate DDD pattern.
How do you solve this in a real world application without doing in memory filtering or leaking Persistence into Domain Layer??
Are there any frameworks which solve issues above with one of the two ways (Query Builder like syntax to Expression Trees or an Expression Tree translator)?
I think Specification pattern is not designed for query criteria. Actually, the whole concept of DDD is not, either. Consider CQRS if there are plethora of query requirements.
Specification pattern helps develop ubiquitous language, I think it's like kind of a DSL. It declares what to do rather than how to do it. For example, in a ordering context, orders are considered as overdue if it was placed but not paid within 30 minutes. With Specification pattern, your team can talk with a short but unique term: OverdueOrderSpecification. Imagine the discussion below:
case -1
Business people: I want to find out all overdue orders and ...
Developer: I can do that, it is easy to find all satisfying orders with an overdue order specification and..
case -2
Business people: I want to find out all orders which were placed before 30 minutes and still unpaid...
Developer: I can do that, it is easy to filter order from tbl_order where placed_at is less that 30minutes before sysdate....
Which one do you prefer?
Usually, we need a DSL handler to parse the dsl, in this case, it may be in the persistence adapter, translates the specification to a query criteria. This dependence (infrastrructure.persistence => domain) does not violates the architecture principal.
class OrderMonitorApplication {
public void alarm() {
// The specification pattern keeps the overdue order ubiquitous language in domain
List<Order> overdueOrders = orderRepository.findBy(new OverdueSpecification());
for (Order order: overdueOrders) {
//notify admin
}
}
}
class HibernateOrderRepository implements orderRepository {
public List<Order> findBy(OrderSpecification spec) {
criteria.le("whenPlaced", spec.placedBefore())//returns sysdate - 30
criteria.eq("status", spec.status());//returns WAIT_PAYMENT
return ...
}
}