Ehsan Ghanbari

Experience, DotNet, Solutions

How to persist a list of value objects in Domain Driven Design

I'm really interested in to write about domain driven design, but it doesn't come into a simple blog post! real world application in Domain driven design approach are usually big, complex and hard to understand the business. I'm gonna to give an example about the persisting the list of value objects, it's just an implementation example that everybody knows the business.

Suppose that we are going to persist the list of tags with blog post. You know, in DDD  value objects should persist with aggregate root and to doing any kind of operation with value object you should talk to aggregate root.

 Fire up visual studio and create a console application or a class library, and put these below infrastructural classes of DDD in it (you can find the implementation of these class on web, it's not the purpose of this post):

 

  1.  public class EntityBase<T>
  2.     {
  3.         public T Identity { get; set; }
  4.     }
  5.  
  6.  public interface IAggegateRoot
  7.     {
  8.     }
  9.  
  10.   public class ValueObjectBase
  11.     {
  12.     }

 Now , create the aggregateRoot class:

  1.   public class Post : EntityBase<int>, IAggegateRoot
  2.     {
  3.     }
  4.  

as I mentioned, I'm gonna to persist a list of value object(BlogTag). so create the blogTag with this definition: 

  1. public class Tag : ValueObjectBase
  2.     {
  3.         private readonly IList<Tag> _tags;
  4.  
  5.         public Tag(IEnumerable<Tag> tags)
  6.         {
  7.             _tags = new List<Tag>(tags);
  8.         }
  9.  
  10.         public string Name { get; private set; }
  11.  
  12.         public IEnumerable<Tag> Tags
  13.         {
  14.             get { return _tags; }
  15.         }
  16.     }

This class has a property named Name and a constructor which initialize the list of Tags, Now refer to Post class (AggregateRoot) and change implement it like this:

  1.  public class Post : EntityBase<int>, IAggegateRoot
  2.     {
  3.         private readonly IList<Tag> _tags;
  4.         public Post(IEnumerable<Tag> tags, string postTitle, string postBody)
  5.         {
  6.             _tags = new List<Tag>(tags);
  7.             PostTitle = postTitle;
  8.             PostBody = postBody;
  9.         }
  10.         public IEnumerable<Tag> Tags
  11.         {
  12.             get { return _tags; }
  13.         }
  14.  
  15.         public string PostTitle { get; set; }
  16.         public string PostBody { get; set; }
  17.     }

This class is entity and also the root of our aggregate, this constructor will be used in service layer, before starting the service implementation create your repository stuff :

  1. public interface IPostRepository
  2.     {
  3.         void CreatePost(Post post);
  4.     }
  5.  
  6.  public class PostRepository : IPostRepository
  7.     {
  8.         public void CreatePost(Post post)
  9.         {
  10.             //Porsist on Dataabase
  11.         }
  12.     }

now it's time jump on service implementation, first create your PostViewModel Class:

  1.  public class PostViewModel
  2.     {
  3.         public string PostTitle { get; set; }
  4.         public string PostBody { get; set; }
  5.     }

 as I'm interested in to request response pattern so let's create the messages of  CreatingPost:

  1.  public class CreatePostRequest
  2.     {
  3.         public PostViewModel PostViewModel { get; set; }
  4.         public IEnumerable<Tag> Tags { get; set; }
  5.  
  6.         public CreatePostRequest(IEnumerable<Tag> tags)
  7.         {
  8.             Tags = new List<Tag>(tags);
  9.         }
  10.     }

As you saw above when I wanted to create the Tag class I created the constructor with accepting the IEnumerable<T> as I want to send a list of tags to persisting, create the response message: 

  1.  public class CreatePostResponse : Response
  2.     {
  3.     }
  4.     public class Response
  5.     {
  6.         public Status Status { get; set; }
  7.     }
  8.     public enum Status
  9.     {
  10.         Success,
  11.         Fail
  12.     }

Finally it's time to implement the Service class and the goal of this article:

  1.   public interface IPostService
  2.     {
  3.         CreatePostResponse CreatePost(CreatePostRequest request);
  4.     }
  5.  
  6.  public class PostService : IPostService
  7.     {
  8.  
  9.         private readonly IPostRepository _postRepository;
  10.  
  11.         public PostService(IPostRepository postRepository)
  12.         {
  13.             _postRepository = postRepository;
  14.         }
  15.  
  16.         public CreatePostResponse CreatePost(CreatePostRequest request)
  17.         {
  18.             var response = new CreatePostResponse();
  19.             try
  20.             {
  21.                 var tag = new Tag(request.Tags);
  22.                 var post = new Post(tag.Tags, request.PostViewModel.PostTitle, request.PostViewModel.PostBody);
  23.                 _postRepository.CreatePost(post);
  24.             }
  25.             catch (Exception exception)
  26.             {
  27.                 Console.WriteLine(exception.Message);
  28.             }
  29.  
  30.             return response;
  31.         }
  32.     }
  33.  

 

Take a deeper look at the CreatePost method of this Service class, by creating the constructor in Tag and Blog you can pass a list of tags via request and put them in Post class constructor and finally send the object  to repository for persisting.

you can get the source code from here, Cheers!



What's the meaning of POCO entity and Persistence ignorance

POCO which stands for "Plain Old CLR Objects" is an entity/class and doesn’t depend on any specific base class. It is like any other Dot net class you have seen before. These POCO entities (also known as persistence-ignorant objects) also support most of the same LINQ queries you use in you Data access layers for your business objects.  POCO is a simple object to be used with a complicated, special object framework such as an ORM component. In other definition POCOs are entities of your domain, so When you use entity framework, these entities are generated for you. You can also use code generators to generate these entities. POCOS are just simple entities without any data access functionality but still gives the capabilities all EntityObject functionalities like Lazy loading and Change tracking

Persistence ignorance means that, as much as possible, anything in your code operating at the business logic layer or higher knows nothing about the actual design of the database, what database engine you're running, or how or when objects get retrieved from or persisted to the database. The domain objects should be ignorant of persistence logic. For example, instead of calling Product.Save(), it's better to call Repository.Save(product). In this way, you get better separation of concerns and avoid exposing persistence semantics on your business objects. The Entity Framework enables you to use custom data classes together with your data model without making any modifications to the data classes themselves. This means that you can use "plain-old" CLR objects (POCO), such as existing domain objects, with your data model. Although these days most of the people like to go through the Code first approach and create their own POCO classes instead of create POCO entities after creating the database.

Notes:

  1. POCO entities are not always needed to be hand-craft.
  2. Lazy loading works with POCO entities.
  3. Entity framework and Nhibernate both support for lazy loading of POCO
  4. POCO cannot use inheritance with your complex type classes
  5. complex types with POCO only supported  Complex Type is class.

 



What's the DDD-lite?

Based on Vaughn Vernon 's definition , "DDD-Lite is a means of picking and choosing a subset of the DDD tactical patterns, but without giving full attention to discovering, capturing, and enhancing the Ubiquitous Language." most of DDD-like approaches are not really DDD! If you don’t have bounded contexts so Ubiquitous language(UL) doesn't mean anything and if you have no UL, you won't have business rules.

In DDD, you should concentrate on domain model and establish a ubiquitous language and use the patterns of DDD. But most of the cases your application is not complex and big enough to apply whole DDD approach. but for more and different reasons you are going to use DDD patterns. For example when your application doesn't have any complex and different scenarios to separate them as bounded contexts or SubDomains - and you just embrace technical tools, concepts and patterns of DDD like simple entities, services, repositories, aggregates. In these cases you can use patterns of DDD within your code and call it "DDD-lite".

I started a project about 10 days ago, it's so interesting that I just read about DDD-lite yesterday; but when I designed the architecture of the project, as I'm really interested in DDD I assigned entities as Aggregate and used repository and layerSupertype patterns, Repository and Service layers. But I don't have any bounded context, value object, subdomain, UL, Domain Service or context map in this project. I've approximately finished the project, I'm gonna to describe the architecture of the project in a few days after hosting in this tag of my blog with "statos" title.

As a usual it's my pleasure you to correct my mistakes, thanks

 

 



Domain driven design VS model driven architecture

Domain Driven design(DDDesign) is not the same Model Driven Architecture(MDA). Although The root of both DDDesign and MDA is the same and it is Model Driven Engineering and also both of them aim to solve the problem of converting a 'pure' problem domain model into a full software system. But there are some differences.

Domain Driven Design concentrates on Modeling and solving the Domain problem by Capturing the model from Ubiquitous language. it is about modeling a domain of knowledge with a high level of abstraction and it's focuses are on domain logic and tries to keep the design as much close to the real world. In DDDesign you create the model with the Ubiquitous language so you should understand the business without any technical issues. In other side model forms the ubiquitous language of DDDesign which explains the domain in a simple form and it's kinda a backbone of DDDesign.

But Model driven architecture is an approach on building the model of the system. As I mentioned MDA is a kind of domain engineering too. A model is just some taken classes, methods and ... from the problem domain. MDA provides you to use multiple standards such UML. 

 

but you know it doesn't stop there, I don't know more than these two paragraphs about differences of DDD and MDA! please let me know more about these two architectures and differences by comments, thanks...



Does CQRS innately need Domain Driven Design?

It's a hard question to answer, or Not? Maybe that's because of my lack of DDD and CQRS understanding. Anyway I'm not sure about what I'm writing in this post to be right and if there is any mistake, please let me know to correct that.

To the best of my knowledge Domain Driven Design is so useful for successfully delivering CQRS based applications but you don't need DDD whenever you want to apply CQRS pattern. CQRS is not intrinsically linked to DDD. CQRS is just a pattern and you use CQRS in a bounded context of a DDD approach. Domain Driven Design allows you to break the complexity of the domain into separate blocks and if CQRS is another way to break the complexity of those blocks to simpler and understandable blocks, you can use it; you can also use CQRS in the whole of your system. CQRS was born in the world of Domain Driven Design and as I mentioned it's not a pattern to encompass the whole application.

"CQRS is a pattern for Task based UI systems" I'm completely sure that You have heard this so many times, haven't you!? Remember that CQRS is a good way to implement task based User interfaces but you can apply CQRS in a CRUD based UI too and task based UI is not part of CQRS. Greg young once blogged a nice post, you can see in the post that "interesting stuff is not really the CQRS pattern itself but in the architectural decisions that can be made around it".



About Me

Ehsan Ghanbari

Hi! my name is Ehsan. I'm a developer, passionate technologist, and fan of clean code. I'm interested in enterprise and large-scale applications architecture and design patterns. I spend a lot of time on software architecture. Since 2008, I've been as a developer for different companies and organizations and I've been focusing on Microsoft ecosystem all the time. During the past years, Read More

Post Tags
Pending Blog Posts
using Elmah in asp.net MVC4
Using FluentSecurity in MVC
Strategic design
Factory Pattern
time out pattern in ajax
Redis as a cache server
How to use PagedList In asp.net MVC
Multiple submit buttons in asp.net MVC
Domain driven design VS model driven architecture
What's the DDD-lite?