Five ‘s Weblog

October 15, 2007

Domain-driven Design

Filed under: Five's thought — by powerdream5 @ 9:14 pm
Tags: , , , , , ,

       Domain-Driven Design(DDD) is an approach of developing software advocated by Eric Evans, one of the experts I really admire. The main purpose of DDD is to place the project’s primary focus on the domain and domain logic, so that softwares will not deviate from their requirement. The facts show that DDD is useful and it can make up the drawbacks of the traditional software developing method. Unfortunately, I think it is not easy to understand DDD totally, which depends on your experience. You also need to apply it to the real projects and summary your experience again and again. To be honest, I just touch DDD a little bit. But I would like to share my thought about DDD with you, and welcome your comments.


       In a domain model, we have five roles, which are separated by their responsibilities. The five roles are Enity, Value Object, Factory, Repository and Services respectively. In the following, I am going to explain them one by one according to my own knowledge.

       Entity: Entity would be the most important part of a domain model, since they are the objects both the clients and software developers concern. Entity has an identity which cannot be changed throughtout the states of the software. In other words, we always need to store the entities in some where, such as database.

       Value Object: Because Entity is the object which has an identity and its identity cannot be changed, it is expenive for the application to create and trace the entity. Considering the performance, it is not reasonbale to mapping all the nouns in your domain model to entities. Value object is the object which does not have an identity, and can be shared by the other objects in your domain model.
       Distinguishing entity and value object would be the first obstacle we meet when we take advantage of Domain-Driven Design, since which object should have an identity and which object should not have is totally decided by the software developers, and there is no rule to direct them to do that. In my opinion, recognizing the entities is similar to mapping objects to tables. Do you remember Embedded value patter? What kinds of objects should be mapped to its own tables and what kinds of objects had better to be mapped to its parents’ table? The answer to this questions depends on your ability of judgement and experience.

         Factory:Factory is responsible for creating the entities. Usually, the process of creating an entity is complex, because an entity always has relationship with other objects in your domain model. When creating an entity, we have to initialize its relationship network. Therefore, it is a good practice to define a kind of objects to encapsulates the procedure of creating the entities.

         Repository:Repository is responsible for managing the entities. Management means updating, saving and loading entities from the database. A repository usually contains an interface and a series of concrete classes implementing the interface. The concrete classes encapsulate the persistent layer of an application.

         Service: After describing the domain, we can map the nouns to entities or value objects and map the verbs to their methods. Sometimes, it is unreasonable to map some verbs to the methods of the entities and value objects. In this case, we create a new role named service containing these methods. Service will define the workflow of the application. Service will be accessed by the client side.

         Thank you for spending time reading this article. Perhaps there are some misunderstandings about DDD in my mind, therefore, if you have any comment, please leave it. For more informatioin about DDD, please check this link.


Blog at