Domain Driven Design Quickly - Book Review

"According to Eric Evans, a domain model is not a particular diagram; it is the idea that the diagram is intended to convey. It is not just the knowledge in a domain expert's head; it is a rigorously organized  and selective abstraction of that knowledge. A diagram can represent and communicate a model, as can carefully written code, as can an English sentence."

A good domain model focuses only on the relevant details and ignores  the rest. There are several ways to communicate the model. The book explains some of the techniques covered by the book Domain Driven Design by Eric Evans.

They are :

1.  Ubiquitous Language


2.  Layered Architecture


3.  Value Objects


4.  Entity Objects


5.  Aggregates


6.  Services


7.  Factories


8.  Repositories

I am not going to explain them all here. You can download a
free copy of the book from info site. I will briefly go over some of them in the context of Rails
projects.

Ubiquitous Language

 We need to find those key concepts which define the domain and the design, and find corresponding words for them, and start using them. Some of them are easily spotted, but some are harder.

Aggregates

In the Code Review session by Marcel Molina and Jamis Buck Aggregates, they show an example where Aggregates is put into practice. They call the Aggregate as the Super Model.

I worked on a Rails project where the User model become bloated with attributes that could be extracted into its own model. For instance, address, contact info, billing info etc. So the User model is
an Aggregate.

Repositories

A good example would be ActiveRecord's find method, given an id it finds the record and returns an object that represents a row in the database.

Development Process and Domain Driven Design

"The Agile methods have their own problems and limitations; they advocate simplicity, but everybody has their own view of what that means. Also, continuous refactoring done by developers without solid design principles will produce code that is hard to understand or change."

I have experienced this on a project where the team was doing TDD and due to simplistic design the code was brittle. The team did not spend much time on design. It seemed like we were going back to
square one once every couple of weeks. The overall productivity of the team went down.

It talks about implicit concept, constraint, process and specification. It provides practical tips on how to refine and improve the initial domain model. I really liked this section of the
book.

Creating the Model

UML can lead to diagrams that are cluttered and hard to maintain. Creating a UML diagram to represent the whole system can result in a huge domain model.

The alternatives are :

1. Create a set of small diagrams with text that explains some aspect of the system which cannot be represented by the diagram. The diagrams can be hand drawn. In the initial stages the domain model
changes a lot, so this is a practical approach.

2. Communicate using code. This is the XP approach. Use well written code as the communication tool. In this case you don't have the problem of documents getting out of sync with the requirement
changes.

The book talks about the Analysis Model and the Design Model and how there is gap between these two models. The developers have to deal with the implementation issues that cannot be foreseen by the analysts.

Bounded Context

I learned this from Rails core team member Marcel Molina during the Advanced Rails studio. At that time I did not know it was explained in the Domain Driven Design book. The idea here is to create a
very cohesive model that is as small as possible.

If required, you can split your application into several applications that have its own domain model. For instance if you have a web application that is about outdoor adventure club management, you can split the billing system into a separate application. This allows the billing system to be used with any system.

I agree with other bloggers regarding the way the Rails team integrates those apps using ActiveResource. It is not a good solution. The ideal way to integrate them would be to use some kind of asynchronous messaging system. This could be as simple as a cron job.

Preserving Model Integrity

This chapter talks about large projects that consist of multiple teams. It describes how to go about applying domain driven design practices.

Conclusion

Domain driven design is not something new, it has been around for couple of decades or so. Eric Evans has documented them very well in his book. It is a must read for any developer regardless of whether you are part of a small or a big team.

In the last chapter where Eric Evans is interviewed he mentions the pitfalls of domain modeling:

1.  Stay hands-on. Modelers need to code.


2.  Focus on concrete scenarios. Abstract thinking has to be anchored in concrete cases.


3.  Don't try to apply DDD to everything.

I remember an interview couple of years ago where the company that interviewed me was very interested in hiring me as a modeler. I never felt comfortable in just being a modeler without getting my hands dirty by writing some code. I am glad that I did not accept the offer, since they never allow a modeler to code.