A filtering logic should be in a repository or in a service

domain-driven-designfilteringsearch

I'm wondering the following: suppose we are building a system where there needs to be some filtering functionality to search for some entity. For example, one might want to apply the filtering to a table listing the entities to find something, or use it to generate a report on a filtered set, whatever.

The point is: we need to have a filtering logic somewhere. One bad way of doing this would be to replicate the filtering logic where needed. I've done that once and it is one terrible idea.

On the other hand, I belive there should be a method like Filter(FilteringOptions filteringOptions) designed to perform the filtering operation and return the filtered list of entities.

Now, IMHO, the filtering logic is a kind business logic. The business experts are the ones who knows how the filtering takes place, what things are filtered and how. Because of that, I believe the filtering logic should be located in the domain layer.

I've found two options for doing this: embeding the filtering method in the corresponding repository for that particular entity, or else, creating a domain service like EntityNameSearchService which would consume the repository to perform the filtering.

I'm still confused which one would be the better way. So, if I'm trying to use DDD properly, where this filtering logic should be? On the repository or in a separate service?

Best Answer

I'm wondering the following: suppose we are building a system where there needs to be some filtering functionality to search for some entity. For example, one might want to apply the filtering to a table listing the entities to find something, or use it to generate a report on a filtered set, whatever.

You should observe that this point that your use cases for filtering center around reads, rather than writes. This is the normal pattern -- a write is typically addressed to a specific aggregate root in your domain.

If you are performing a read, then you don't actually care about aggregates - you don't care about the enforcement of the business invariant because you aren't actually trying to change anything. You just care about state.

Which may mean that it makes sense to bypass the domain model completely.

Just something to think about.

Now, IMHO, the filtering logic is a kind business logic. The business experts are the ones who knows how the filtering takes place, what things are filtered and how. Because of that, I believe the filtering logic should be located in the domain layer.

Yes, and no. You are drawing upon the ubiquitous language to describe the filter. So you are definitely using the domain vocabulary.

But you don't have any "behavior", in so far as you aren't actually modifying the book of record, so you don't have the invariant to worry about.

On the other hand, I belive there should be a method like Filter(FilteringOptions filteringOptions) designed to perform the filtering operation and return the filtered list of entities.

You are very close to the idea of "Specification". It's basically a predicate than a repository can use to identify which artifacts match some arbitrary criteria.

There are some traps to be aware of. Greg Young touched on them some time back, but I'll summarize here.

First, the abstraction of running a predicate against a collection is O(N). You'll probably want something nicer, especially if your persistence store is smart about indexing. Your persistence component will likely want to be able to transform it to a implementation specific constraint (example: taking a specification and turning it into a where clause on a prepared statement).

Second, an interface is a means of documenting the contract served by the persistence component. "Make the implicit explicit" -- if you describe what it is that you really need, then the interface tells you something about what characteristics are important for your data store, which gives you a single place to look when trying to evaluate whether an alternative store is suitable.

(Of course, the implementation of that interface might just be an adapter that creates the specification from the method arguments, and forwards that along. That's OK, you've captured the actual requirement).

Related Solutions

Domain-Driven Design – Should the Repository Be in the Domain Object or Service Layer?

You can take either approach and have it work well - there are, of course, pros and cons.

Entity Framework is definitely intended to suffuse your domain entities. It does work well when your domain entities and data entities are the same classes. It's much nicer if you can rely on EF to keep track of the changes for you, and just call context.SaveChanges() when you're finished with your transactional work. It also means that your validation attributes don't have to be set twice, once on your domain models and once on your persisted entities - things like [Required] or [StringLength(x)] can be checked in your business logic, allowing you to catch invalid data states before you try to do a DB transaction and get an EntityValidationException. Finally, it's quick to code - you don't need to write a mapping layer or repository, but can instead work directly with the EF context. It's already a repository and a unit of work, so extra layers of abstraction don't accomplish anything.

A downside to combining your domain and persisted entities is that you end up with a bunch of [NotMapped] attributes scattered throughout your properties. Often, you will want domain-specific properties which are either get-only filters on persisted data, or are set later in your business logic and not persisted back into your database. Some times, you'll want to express your data in your domain models in a way that doesn't work very well with a database - for example, when using enums, Entity will map these to an int column - but perhaps you want to map them to a human-readable string, so you don't need to consult a lookup when examining the database. Then you end up with a string property which is mapped, an enum property which isn't (but gets the string and maps to the enum), and an API which exposes both! Similarly, if you want to combine complex types (tables) across contexts, you may wind up with a mapped OtherTableId and an unmapped ComplexType property, both of which are exposed as public on your class. This can be confusing for someone who isn't familiar with the project, and unnecessarily bloats your domain models.

The more complex my business logic/domain, the more restrictive or cumbersome I find combining my domain and persisted entities to be. For projects with short deadlines, or that don't express a complex business layer, I feel that using EF entities for both purposes is appropriate, and there's no need to abstract your domain away from your persistence. For projects which need maximum ease-of-extension, or that need to express very complicated logic, I think you're better off separating the two and dealing with the extra persistence complexity.

One trick to avoiding the trouble of manually tracking your entity changes is to store the corresponding persisted entity ID in your domain model. This can be filled automatically by your mapping layer. Then, when you need to persist a change back to EF, retrieve the relevant persistent entity before doing any mapping. Then when you map the changes, EF will detect them automatically, and you can call context.SaveChanges() without having to track them by hand.

public class OrganisationService
{
    public void PersistLicenses(IList<DomainLicenses> licenses) 
    {
        using (var context = new EFContext()) 
        {
            foreach (DomainLicense license in licenses) 
            {
                var persistedLicense = context.Licenses.Find(pl => pl.Id == license.PersistedId);
                MappingService.Map(persistedLicense, license); //Right-left mapping
                context.Update(persistedLicense);
            }
            context.SaveChanges();
        }
    }
}

C# – Separation of concerns between repository and service in DDD with complex entities

Sounds like you are using domain entities for both domain operations (commands, which modify application state) and queries (which don't modify application state, but return data for the user). The problems you describe are a direct result of trying to get that single domain entity to do both jobs, which don't mix very well.

My recommendation is to read on CQRS (Command Query Responsibility Segragation) e.g. CQRS by Martin Fowler and try to limit your domain entities to only retrieve what data they need to complete the domain operation. Even though the amount of classes and interfaces will grow, your application will become much more simple and more maintainable due to more adherence to the Single Responsibility Principle.

Also, your choice of domain objects and especially Aggregate roots leads me to question the validity of your domain model. Is a File really such an entity, that it's of dire meaning to the business people? What kind of operations do you do on the file, and what's their value to the business? The whole idea in Domain Driven Design is to identify the actual business entities on which you should act, as if you wouldn't have a computer at all. An Order is a common example. Operations on that Aggragate root would be "Submit", "Cancel" etc. File is just an infrastructural concern, which most often has no value or place in the domain logic.

Best Answer

Related Solutions

Domain-Driven Design – Should the Repository Be in the Domain Object or Service Layer?

C# – Separation of concerns between repository and service in DDD with complex entities

Related Topic