Software Developing: Domain Driven Design

Software Developing: Domain Driven Design

Being a fan of Domain Driven Design and using that kind of design daily at my work I thought it would be interesting to write about it. Even if some still think it's just a buzz word it's not, and at FenixEDU I think we have proved that. Keep in mind that what's written it is my opinion only and it may not reflect the opinions of my co-workers nor my employers.

But if it's not only a buzz word, what is it?
To understand what Domain Driven Design is first you need to know how an application is usually divided. Most of the time, it's used what we call a 3 tier architecture where each tier - or layer - has a different responsibility:

• The lowest one is what we call the data layer (or prevalence layer) and it is responsible for storing and retrieving all the application data in a certain way, which can go from database storage to live storage in memory (if you're interested in knowing more about memory storage, you can check, for instance, Prevlayer);
• The second layer is responsible for the business logic, anything related with the problem itself should be there. Examples are: how many objects Y object X can have, or method M can only be accessed in the context C should be here;
• Finally, on the top you have the presentation layer which is responsible to display the processed information to the user.

Domain Driven Design is not a technology nor a methodology, but a way of thinking on how to develop within the business logic layer. Such way of thinking consists in the following:

• Finding a model for your problem;
• Creating objects and their relations according to the problem (this is what we call the domain model);
• Creating the business logic inside those objects.

Nowadays such architecture is not widely used, instead an Anemic Domain Model is used having most of the logic - or all of it - within a set of services.
An Anemic Domain Model, is a model which has the objects and the relations but lacks the business logic. It acts mostly like Data Transfer Objects (DTO) which find most (or all) the logic within the services, you can read more about such domains at Martin Fowler's bliki.
In this kind of approach, you're not actually doing a purist Object Oriented design, since the object behaviour is not within the object but rather on the service - almost like an utilitary class - and the domain objects itself are mainly data structures. With such design it's also easier to have replicated code (although this one can be avoided using good practices).

But do not think that the problem is the existence of a service layer. This layer is also present with Domain Driven Design, but instead of a thick layer filled with logic -which in my opinion is one of the biggest problems in the Anemic Domain Models-, this layer becomes a thin one which is used to give transactional context to safely operate with your domain objects. With such approach the services stop having the domain logic.
Service layer may also give you some sort of access control policies, although following a true OO philosophy you should put such logic within the object using techniques like code injection.

Having the business logic centred on the domain objects is good, because with that you centralise all the behaviour within each object. So when you need, for example, to change some sort of behaviour you just need to change the code inside the object and it's most of the time self contained.

With Domain Driven Design you have to ask yourself, "I have this model, and these functionalities, in which object do they belong?". Then in the thin service layer that exists there's only the need to call the methods within the objects that map those functionalities.

Then at the services you just have to call the methods within the objects that map such functionalitys.

Another property of Domain Driven - although Anemic Domain Models also have it - is the ability to navigate in the domain, this is possible due to the relations between objects that have been created to construct the domain model. So this for example if you have the two objects, for example, Department and Person with a model like the one in the figure. The Department object should have the methods that allow you to list, add and remove Person objects to the Department and vice-versa for the Person object.
With such a simple example, it doesn't seem that handy although when you start having complex domains with many relations such navigation turns out really handy.

Even being an enthusiast about such kind of architectures, I'm not obsessed with it, so if you have a really simple application with a small model probably there's no need to implement such kind design, a simple architecture with DTOs, and transactions scripts should do the trick, though such solution is not very scalable.
Another thing I know is that creating all the relations, along with their persistence, is difficult. My suggestion, is that if you want to go for this kind of design, use a domain model generator. At FenixEDU we have our own domain generator, which reads the domain model - includes objects from the model and their relations - and generates all the code of those objects, along with their relations and persistence code, you can read more about it in our wiki.

Some people might think design doesn't really matter, but after being for one year and an half developing with domain driven - and also getting totally addicted - I have to say that it does matter! I'm not saying it's the best way of developing, but at least is the best way i know to develop.

The idea of this post is not only to show about the main ideas of what domain driven design, but also to generate questions and discussion about it. So please feel free to comment. I'm looking forward for it.