Is DDD not appropriate for the website or should I introduce a Query Layer

domain-driven-designentity-frameworkobject-oriented-design

I have inherited an ASP.NET website application and the previous developer has used what I believe are some DDD concepts. I am new to DDD and I have to admit I am struggling with the practical side of it having come from an N-Tier Transaction Script background.

One of the problems with the site is that it is slow. There is no paging on huge grids and also the business logic layer pulls down way more data than is needed for 90% of operations 70% of which are reads to bind data to grids.

The general design is that the business logic layer has a Service class per aggregate root, with various "GetByX()", 'FindBestMatching()" and "Update()" type methods on it. These Service classes are the points from which trees of domain objects are created such as "Organisation" and "User."

Back in my comfortable transaction script days, my service layer was similar: there would be some logic possibly, a call into a repository (or since EF 6 direct use of EF as it can be mocked for testing) and then the call would return. The objects that were returned would be DTO type objects containing return data relevant, including possibly some POCO entity objects. These DTOs would travel to clients via webservices, be bound to ASP.NET or Silverlight grids…all was good.

My operations on my service layer could be very specific, allowing for queries like:

"GetUsersWithSurnameIncludeChildren(string surname, int skip, int take)"

allowing for nice narrow DB queries that supported paging and eager loading of related data. It was fast and loaded only the data that was actually needed.

Now with this site I have inherited there is an actual OO model of the business domain. These classes are POCOs, not generated from EF, but EF is used database first as a repository (there is a lot of mapping between the domain objects and the EF objects). An example domain object is below (without any logic).

public class Organisation
{
    public int OrganisationID { get; set; }
    public string Name { get; set; }

    public IList<Organisation> AssociatedOrganisations { get; set; }
    public IList<User> Staff { get; set; }
    public IList<User> Managers { get; set; }

    // Business logic method implemented below here
}

Many of the classes are essentially copies of the underlying entity framework objects, others have a significant amount of logic encapsulated within them.

The way the site works currently is that every time the OrganisationService service class creates a new Organisation domain object (and it may create a collection in one hit) it also populates ALL of the fields and collections in that object…and all of the fields and collections in those objects! A huge deep tree is created in memory and a stack of joins and unions (generated by EF) is needed to get all of the data. This is totally inappropriate for a website that mainly displays loads of flat grids.

My questions are:

1) Is an application that is 70% pulling data out of a DB for display and 30% business logic actually a bad candidate for DDD?

2) If DDD is appropriate how are scenarios like this generally designed? Should I implement a separate "Query Service" that is designed just to pull out loads of flat data for binding to pages and grids (these could just be the EF POCOS themselves) and reserve the Domain objects just for parts of the application where logic must actually be performed?

3) Should I only load data into my Domain Object reference types and collections when it is actually accessed (like EF lazy loading…)? Previous posts I have read have suggested lazy loading in a Domain Object is a code smell: DDD Lazy Loading Code Smell

I am about to buy a DDD book tonight 🙂

Best Answer

After you read Evans' book, you will see that DDD is a collection of concepts. The book was written over a decade ago. My opinion of it today is that it has good parts but is easily misunderstood and sometimes used inappropriately. In reality, some parts you may not need or may not be right for your application or chosen tools.

As far as EF, I don't think that the DDD concept of combining data and behavior in your entities melds well with it. EF entity models should be devoid of behavior if you want to avoid a lot of unexpected errors and performance bottlenecks. As other answers here point out, using a CQ(R)S pattern is a good way of implementing behavior externally from EF entities. Bottom line is, try to avoid implementing a "rich domain model" using methods on EF entities. You can still crunch the business knowledge into "the model", but your "model" should contain different classes for data (entities) and behavior (operations).

I also don't like the idea of repositories, but that's primarily my opinion and I'm sure others will disagree when I say they really aren't necessary when you are using an ORM like EF. Maybe a decade ago, before we had modern generics, they were more useful. These days, you can wrap a single generic interface around an EF DbContext and have a single generic repository (along with unit of work).

On the other hand, things like the ubiquitous language, aggregate roots, bounded contexts, query criteria, etc. I consider to be pearls. Keeping the application layer thin is a timelessly good practice too. It sounds like the other developer might not have applied the appropriate DDD concepts, and as someone else here already said, created more problems than they solved.

"Yes, you're doing things right."

Rarely are we given a clean and ideal architecture to work from. Heck, rarely are we even given an architecture, period. Small consolation, I realize. But you're asking the right questions and taking the right approach.

One thing you may not have realized is that isolating the EF layer and the database access is a step towards encapsulating the changes the application is seeing. Juval Lowy of iDesign is a huge advocate of encapsulating the change. Change is good because it keeps us employed and keeps our applications alive, but we want to limit the impact any change can have upon the rest of the application. So we encapsulate it.

You can't lower the volatility of your domain (note, I didn't say domain model) and you wouldn't want to even if you could. All you can do is encapsulate that volatility. Once you isolate the volatility of your domain, then your domain model will fall in line.

Identify the areas of your database that seem prone to most frequent change. Isolate out those aspects so you can more easily make the changes while minimizing downstream impact. Using a data access layer is a good start. It might be time to consider a sub-layer for data access that allows you to create a composite of those for the main DA layer.

Some people love EF, some people really don't see much advantage to it when weighed against the costs. Of those who use EF, they tend to work with the latest release of that toolset. The recent (v4.5?) updates have made EF more usable / workable. Wether or not it's a good technological decision for you is something that only you can decide. Look at your alternatives; examine the cost to switch to those; and move forward. As a suggestion, create a test branch in your repository, migrate away from EF on that branch and work through some of the challenges. Then you'll know.

The performance issues within your database imply that you need to consider some restructuring. Normalization, in moderation, is a good thing. It's easy to go overboard with it, but restructuring your tables so that they are more easily indexed will likely help with the performance issues. This could also help with encapsulating some of the change you're seeing from updates to the applications.

For example, you may have a table CustomerInfo with a primary key of CustomerID. If App1 is adding / changing ancillary columns off of CustomerInfo then you can give App1 it's own subtable CustomerInfoExtensions keyed back to CustomerInfo with the CustomerID.

I don't know of any data access approach that will fix bad structure within the database tables. So you may be "blaming" EF in this case when the root issue lies in the DB. And there are no silver bullets when it comes to crunching huge data sets. If DomainInclude<Customer>.Include("Orders").Include("Friends") creates a cartesian product across your largest tables, well, then that will simply be your least performant query. Fix the query before worrying about the data access method.

Exposing an IQueryable isn't necessarily a bad thing. If you need (want) a more concrete expression of that Interface, then pick an appropriate generic container. We pass collections around like that all the time, and it makes using the MVVM pattern a lot simpler to implement when displaying the data. I think your concern here is that you feel there should be something "more" to what the EF layer is returning. If an IQueryable is sufficient, then use one. If you need a first class data object on the return, then create one. But don't create a first class data object just to have one if the IQueryable is good enough. That would be extra work.

The question of DevExpress vs. other datagrids leads me to an answer of "meh." You've got bigger challenges to resolve first before worrying about that one. Consider the UI (View) as an area that will change. Encapsulate it. When you decide you hate FooBar-Grid (or whatever is your current flavor of UI) then you can get rid of it more easily. Personally, I would worry about enhancing the DB and data access layers first, but I'm an engineer who appreciates the simple elegance of the command line. Call me biased.

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();
        }
    }
}

Best Answer

Related Solutions

Evaluating Architecture: Am I Doing Things Right?

"Yes, you're doing things right."

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

Related Topic