Creating a Stable Code Base
Filed under: Agile, Domain Driven Design, Technical, Test-Driven Development — Dave Sammut @ 11:53 am
Implementing Domain Driven Design – Creating a Stable Code base
This is the second part of my experience on applying Domain-Driven Design (DDD) on a recently completed project for a major blue-chip company. In the last post, I showed how by using DDD we managed to reach a consensus between the technical and business people through common terminology.
In this post I will talk about a more technical achievement that was possible thanks to DDD.
Given the tightly coupled nature of the application and the framework we knew it would be a challenge for us to create a true implementation of the domain model we created.
We decided to use our DDD concepts to create a Layered Architecture which allowed us to introduce the use of entity, value object, repositories, factories and services With this approach, different modules were created which were all assigned a behavioural responsibility. After several team discussions and hardcore development, we created an application framework which we were confident that it satisfied all the key areas of responsibility. This also meant that we application framework would be able to meet the key business requirements that mapped the code to the domain model.
Using this approach, gave us the benefit of having loosely coupled modules where each module adhered to their declared behavioural responsibility (high cohesion) and opened the door to a test-driven development approach. The key business modules and supporting modules had a good unit-test coverage which gave us a stable core code base to build upon (expressed through Interfaces).The framework, however, did pose some limitations and so we were not able to unit-test all modules.
The framework also had other limitations. Where possible, we introduced Interfaces for classes that lacked them and when the altering the original class was not possible, we applied the proxy pattern.
Our development was driven by User Stories. Using the Layered Architecture from DDD allowed us to focus on completing the development of one story at a time. This was achieved by ‘injecting’ dummy implementations at different layers which allowed for different areas to be worked on simultaneously without impeding development on separate layers.
Through the domain diagrams we managed to achieve:
- High unit test coverage of the core code-base,
- Abstraction from the framework to allow us to map the code to the domain model,
- Developers became familiar with the implementation patterns that emerged which sped up development,
- Developers found it easier to debug issues as they knew which module was responsible for what, and
- The technical team used the same business terminology to discuss the code-base.
In the next and final post on this subject I will share my experience of how DDD helped us meet our business and technical acceptance tests.