{"id":1893,"date":"2014-10-30T00:00:00","date_gmt":"2014-10-30T00:00:00","guid":{"rendered":"https:\/\/test.simple-talk.com\/uncategorized\/take-your-crud-to-the-next-level-with-ddd-concepts\/"},"modified":"2021-05-17T18:35:59","modified_gmt":"2021-05-17T18:35:59","slug":"take-your-crud-to-the-next-level-with-ddd-concepts","status":"publish","type":"post","link":"https:\/\/www.red-gate.com\/simple-talk\/development\/dotnet-development\/take-your-crud-to-the-next-level-with-ddd-concepts\/","title":{"rendered":"Take your CRUD to the next level with DDD concepts"},"content":{"rendered":"
\n

Let the journey begin<\/h2>\n

There is a skill that I particularly admire in a developer: It is being able to recognize correctly that something, whether code or process, is no longer working well.  It is useful because a project will so often start with right architecture and design but, over time, travels in unexpected direction. Without this skill, the project is liable to cross the ‘fit-for-purpose’ border and enter into ‘big-ball-of-mud’ land. Why? The project has changed, but the architecture hasn’t. No architecture is suitable for all types of software development project, yet we, who are assumed to be specialists, tend to be too eager to use the same solution for different problems. As in so many of life’s problems, ‘one size does not fit all’.<\/p>\n

Many solutions start as mainly routine CRUD requirements (Create, Read, Update and Delete) but usually with some specific part that has considerable complexity. Software architecture should address those two areas separately. DDD (Domain-driven design) might seem a perfect tactic to address complex requirements, but it relies on access to domain experts and a shared intent to focus primarily on the domain and refine it iteratively.<\/p>\n

Even when these prerequisites aren’t available, DDD might still be an inspiration for structuring code in these more complex areas of a development project because, in large part, it is plain good OOP. Such an approach, without defined context, ubiquitous language or even communication benefits, is called DDD-lite. It concentrates on technical-side patterns and concepts. Of course, it doesn’t mean that we forget about domain or communication – those elements are still present, but they are not at such a high level; nor are they explicit enough to warrant calling the approach ‘DDD’.<\/p>\n

Aggregated root and action classes<\/h2>\n

Let’s look at how complexity may creep in your model, and how DDD concepts may help. Imagine we are implementing a classic ASP.NET MVC application with following layers:<\/p>\n

\t\"2082-img25.gif\"<\/p>\n

MVC controllers execute business logic that is kept in the domain and this logic is exposed through a façade of application services, which use repositories to access the database. Entity Framework’s DbContext<\/code> is internally used to implement repositories.<\/p>\n

For the sake of example, let’s assume that we start with the following model:<\/p>\n

\"2082-img21.jpg\"<\/p>\n

We have a customer with a name and addresses. A customer can create orders – each one has delivery date, addresses and set of ordered products.<\/p>\n

Initially our code may look similar to this:<\/p>\n

\t\t     public  class  OrderRepository\n\t\t     {\n\t\t          public  IList<Order> Find(Customer customer)...\n\t\t          public  Order Get(int id)...\n\t\t          public  void Save(Order order)...\n\t\t     }\n\t\t\n\t\t      public  class  OrderLineRepository\n\t\t     {\n\t\t          public  IList<OrderLine> Find(Order orderline)...\n\t\t          public  OrderLine Get(int id)...\n\t\t          public  void Save(OrderLine orderline)...\n\t\t     }\n\t\t\n\t\t      public  class  OrderService\n\t\t     {\n\t\t          public  IList<Order> Find(Customer customer)...\n\t\t          public  Order Get(int id)...\n\t\t          public  void Save(Order order)...\n\t\t     }\n<\/pre>\n
Two repositories, Order<\/code> and OrderLine<\/code>, give  access to the respective tables through a set of base operations. Order service  combines those and exposes logic to higher layers. A Find <\/code>method on service, for example,  could be as simple as calling Find<\/code> on OrderRepository<\/code> and returning only  order headers. The Save<\/code> method, on  the other hand, invokes Save<\/code> on OrderRepository<\/code> and iterates over  order lines to persist each of them with the OrderLineRepository <\/code>class: All  reasonably good so far.<\/p>\n
Now, let’s imagine that the customer  changes his mind or we suddenly find out that the save operation is more  complex. Depending on the order status, we have to perform a basic or more  sophisticated validation. I often witnessed service evolving into something like  that:<\/p>\n
\t\t     public class OrderRepository\n\t\t     {\n\t\t         public IList<Order> Find(Customer customer)...\n\t\t         public Order Get(int id)...\n\t\t         public void Save(Order order)...\n\t\t     }\n\t\t\n\t\t     public class OrderLineRepository\n\t\t     {\n\t\t         public IList<OrderLine> Find(Order orderline)...\n\t\t         public OrderLine Get(int id)...\n\t\t         public void Save(OrderLine orderline)...\n\t\t     }\n\t\t\n\t\t     public class OrderService\n\t\t     {\n\t\t         public IList<Order> Find(Customer customer)...\n\t\t         public Order Get(int id)...\n\t\t        public  ValidationResult Save(Order order)...\n\t\t          public  ValidationResult Submit(Order order)...\n\t\t\n\t\t          private  void SaveOrder(Order order)...\n\t\t          private  ValidationResult ValidateOnSave(Order order)...\n\t\t          private  ValidationResult ValidateOnSubmit(Order order)...\n\t\t     }\n<\/pre>\n
There is a new public method to submit  an order. Save<\/code> and Submit <\/code>internally call the appropriate private method to do the  validation (ValidateOnSave<\/code> or ValidateOnSubmit<\/code>). As the actual  logic of order saving is common it is extracted into separate private method (SaveOrder<\/code>).<\/p>\n
If developer writing this piece of code  would know DDD better, a solution might look like this:<\/p>\n
\t\t     public class OrderRepository\n\t\t     {\n\t\t         public IList<Order> Find(Customer customer)...\n\t\t         public Order Get(int id)...\n\t\t         public void Save(Order order)...\n\t\t     }\n\t\t\n\t\t     public class OrderLineRepository...\n\t\t\n\t\t     public  class  OrderValidator\n\t\t     {\n\t\t          public  ValidationResult ValidateSave(Order order)...\n\t\t          public  ValidationResult ValidateSubmit(Order order)...\n\t\t          private  void ValidateCustomerLimits()...\n\t\t          private  void ValidateOtherLimits()...\n\t\t     }\n\t\t\n\t\t     public class OrderService\n\t\t     {\n\t\t         public IList<Order> Find(Customer customer)...\n\t\t         public Order Get(int id)...\n\t\t         public  ValidationResult Save(Order order)...\n\t\t          public  ValidationResult Submit(Order order)...\n\t\t     }\n<\/pre>\n
One of key technical concepts of DDD is  aggregated root. This is the parent entity, which controls access to its  children, defines their lifetime and takes care about concurrent access to the  same objects. This way, aggregate root can ensure the integrity of aggregates as  a whole. All repositories should operate at aggregated root level. No other  entities should be exposed directly through the methods of repository. That is  the reason why OrderLineRepository<\/code>  has been removed. With the full logic of saving Order <\/code>and OrderLine<\/code> in  the repository, there is no need to have a separate SaveOrder<\/code> method on  OrderService<\/code> – this kind of logic is better kept at repository, where it is  easily mockable and testable.<\/p>\n
One addition – there is a new class, OrderValidator<\/code>, named after an action  and replacing logic that was kept previously in the private methods of OrderService<\/code>. Contrary to what we  have learned during Computer Science studies, it is better to not only call your  classes after nouns, but also verbs. In our case, all the logic that is related  to order validation is now kept in a separate class with single responsibility.  Sub-validations, constituting on full validation, can be kept is private methods  of OrderValidator<\/code> (e.g. ValidateCustomerLimits<\/code>). If we would  need access to other areas of domain model inside OrderValidator<\/code>, we can easily inject dependencies into that class  without increasing overall class coupling too much and still have testability at  the same level.<\/p>\n
Domain events<\/h2>\n
Next, the customer might express a  requirement to send an email notification to its recipients, and for legal  reasons might need to generate an invoice at the time of order submission. A  sufficient implementation, which often comes to mind could looks like this:<\/p>\n
\t\t     public class OrderRepository...\n\t\t\n\t\t      public  class  EmailTemplateRepository\n\t\t     {\n\t\t          public  EmailTemplate Get(EmailTemplateType type)...\n\t\t     }\n\t\t\n\t\t      public  class  InvoiceRepository\n\t\t     {\n\t\t          public  void Save(Invoice invoice)...\n\t\t     }\n\t\t\n\t\t     public class OrderValidator...\n\t\t\n\t\t     public class OrderService\n\t\t     {\n\t\t         public IList<Order> Find(Customer customer)...\n\t\t         public Order Get(int id)...\n\t\t         public ValidationResult Save(Order order)...\n\t\t         public ValidationResult Submit(Order order)...\n\t\t\n\t\t          private  void SendEmailNotification(Order order)...\n\t\t          private  void CreateInvoice(Order order)...\n\t\t     }\n<\/pre>\n
We have new repositories:<\/p>\n