Experience with Domain Driven Design

Recently, while having a discussion with a group of colleagues that are new to the Domain Driven Design (DDD) approach, some points highlighted by these colleagues truly reflect how I first felt when I tried to understand the approach from the book and applying it. Probably for anyone new to this and like to apply the DDD, the whole approach can be sub divided into a few areas to provide a better segregation of understanding and implementation.

Understanding the concept
I will say that it is not that difficult to understand the concept from reading the book. The first part of the book with the first three chapters well describes the concept. This concept covers mainly the design approach with DDD. Personally, I think the concept is powerful, clean and easy to understand and use to drive most design. With part 1 of the video by Eric Evan on InfoQ a better picture can be provided straight from the horse’s mouth. Having a good understand of the concept is important before moving into the implementation.

Driving the Design
Modeling is the main utility in the DDD. The concept used, clearly defined how to design the model and how everyone within the project use the model as the backbone for discussion to the actual implementation in codes. This clearly reflects back to the concept of DDD. One important factor during the design is not to add other complexity such as infrastructure into the design and the domain model. So far, there wasn't much problem with the adoption of this approach during the design phase and the domain model really provide the team with a solid backbone from the design to the implementation.

Implementation of the Design into Codes
If you have noticed, I have not said much of the concept and driving the design much above, as I believe what is mentioned in the DDD book is more than enough to give you a good start. However do note the following remarks found in chapter 3 of the book:

Developing a single model that captures the problem and provides a practical design is easier said than done. You can't just take any model and turn it into a workable design. The model has to be carefully crafted to make for a practical implementation. Design and implementation techniques have to be employed that allow code to express a model effectively. Knowledge crunchers explore model options and refine them into practical software elements. Development becomes an iterative process of refining the model, the design, and the code as a single activity.

To me, the actual complexity of the whole DDD approach is in the implementation of the design into codes. This is the greatest barrier I had when I first tried to transfer the design into codes. In part two of the DDD book, certain design patterns are mentioned on how the design or model can be implemented into codes, however I find these part can be greatly improve on. Even after reading the Applying Domain Driven Design and Patterns with Examples in C# and .Net by Jimmy Nilsson does not help much. Not trying to say that the book is not good, but just probably not enough to transits from the design into codes.

Phillip Calcado has written an article on Repository Trouble and I believe this is another example of how much certain doubts on the implementation are not clearly explained and probably due to the lack of example. From my understanding, the main responsibility of the repository as mentioned in the book:

Hide all the inner workings from the client, so that client code will be the same whether the data is stored in an object database, stored in a relational database, or simply held in memory. The repository will delegate to the appropriate infrastructure services to get the job done.

Example

In a domain with a user object, this user will probably have a few implementation methods such as create user, inactive user, get user information and many others... Each method will need to persist or retrieve the user object, but each method should not be aware of where this information is persisting thru DAO or LDAP or even file. The repository should take care of this responsibility and in return hiding the persistence and the infrastructure from the domain layer. Without this repository, each method will be required to know where to persist each object.

Other than what is mentioned, the repository also help to enforce certain domain logic such as preventing queries from pulling exact data rather than navigating from aggregate roots.

Will continue to discuss more on the DDD implementation in subsequent post...

Additional videos by Eric Evans
Part 2: Strategic Design
Part 3: Domain-Driven Design and Domain Specific Languages

Discussion with Jimmy Nilsson

Last week, my company has engaged Jimmy Nilsson to provide a consultation to a new project that we are working on. During this period, my colleagues and I had an intense discussion with him on topics like Domain Driven Design (DDD) and Test Driven Design (TDD). The discussion has opened up a lot of approaches, concepts and ideas to our new project. New to these topics and having read a few books on them, this discussion really provide a better picture of those missing part found in the books and clear up some of the assumption we have made.

Where is the most complex part of an application? Usually, the domain layer of the application is the most complex part as it contains the different complexity found in different domain. Therefore, design and maintenance of the domain complexity can be one of the greatest challenges in a big project. The book Domain Driven Design Tackling Complexity in the Heart of Software by Eric Evans provides a good idea of how this challenge can be managed and overcome. Together with TDD and Agile software development approach, the book Applying Domain Driven Design and Patterns: With Example in C# and .NET by Jimmy Nilsson provide another approach of applying the DDD with.

During the discussion, Jimmy has given another definition of his on the TDD, which the focus is not only on testing, but also to be used as a driving tool for the domain design. The idea of this approach is to think and let the design evolve as the codes are written. As a team using this approach, he or she should not be afraid of changes. In software development, what is not changing is the amount of changes that we are seeing throughout the development lifecycle. As for how good the DDD and the Agile approach will turn out to be, I will come back again to review it as the project mature.