After I listen to a podcast made by Ron Jacobs and with Jefferey Palermo, and also after looking at other people’s design and ideas and questions etc. I notice that some developers think they use Domain Driven Design (DDD) because they use an OR-mapper, they use entities, and they use Repositories etc. I’m not alone, even Patrik Löwendahl has notice similar things and you can find his answer to a question by clicking here.

I can create an app today that uses an object that for example reflects a Customer, I could also separate the logic about how to fill the Customer with data out from the entity into separate classes (for example creating a class and name it CustomerRepository the will give me a Customer). By doing this I have code like this:

Customer customer = CustomerRepository.GetCustomerByNo(“1000”);

Because I have created an entity Customer and a “Repository” class, it doesn’t mean that I use DDD. This is a common way of writing applications; but some people use the word Manager instead of Repositories etc.  The reason some developers use this approached instead of using ActiveRecord [PoEAA], is to separate the logic of doing a “data access” from the entity. Some developers use the Active Record pattern and like it. For about two years ago I helped a company applying part of DDD. Some month later he asked me a question about aggregate and sends me some example code. When I look at the code I see this:

customer.Save();

A typical Active Record pattern. I asked him why he doesn’t want to separate the way of saving the Order into a separate class. His respond was “I like this way better, for me it’s easier to understand and I think this kind of design is obvious in my application”. Then he told me “If you was the customer, would you like to let someone else put your cloth on or off?”. He wanted to give the responsibility of letting the Customer decide how he want to put the cloth on or off, not letting another one doing it for him, “Object thinking”. In this situation a friend of mine should probably reply:  “should the customer take a photo of himself?”  Even if he uses the Active Record pattern, he still uses DDD (I convince my friend to separate the data access logic from the entities). But what I will get to is that DDD has nothing to do with Repositories etc. DDD is a way of thinking and is a help to minimize the gap and misunderstanding between the business “activity” and the developer, make them get together closer to maximize the understanding of each other.  From the customer’s needs and business, we create a model together with the customer where we use the same language, so both understand each other “Ubiquitous Language”. This model is what the customer sees; this model is what the developers will turn into code by using object-oriented techniques and different patterns and practices etc. What Evans do in his book about DDD, is to give us his ideas of how we can turn the model we have created together with a domain-expert into code, based on what he notice is a good way to solve the problem of dealing with complicated domains. If a developer use the Evans patterns of using Repositories and create entities, is not even sure the developer uses DDD, because a developer can still use similar patterns for filling and getting entities in the applications. The domain-model we turned into code, by using entities etc, should not pay any attention or concerns about how we should get the data in the first place. It’s more important that we understand the domain-expert and can turn the domain-model into code, than focus on the implementation of the data-access.