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.
Filed under: Remote, Technical — Dave Sammut @ 1:19 pm
Implementing Domain Driven Design: Domain Diagrams – Dave Sammut
My team and I just completed a project where I believe that our knowledge of domain-driven design allowed us to complete an application based on a rigid framework with an aggressive time-to-market deadline. Unlike other web-applications we have made for the same parent project, this sub-site had a complex content model complimented with complicated business logic. The rigid framework we had to use had many page components with a long list of super classes which hindered any approach to a test-driven application development as the domain items (the business logic) was tightly coupled with the framework’s core architecture.
In this post I would like to show how the usage of Domain-Driven Design (DDD) allowed us to achieve our business goals.
At the beginning of the project, we received a set of documents that expressed the main business logic and the Information Architecture (IA). However, when we started to dig into these documents, we found inconsistencies with the business logic and the way different terms were used. In other words, there was no common vocabulary or agreement on business reasons for the requested business objects.
Having used DDD in previous projects, I took a stab at introducing my understanding of the application domain through the use of numerous diagrams. By application domain I mean the business logic, content models, object relationships, constraints, etc.
The introduction of a new process is always met with resistance and none was spared here. However, the diagrams sparked discussions and increased communication between myself, the technical architect and the business analysts. Through this process the I attained a deeper insight in the complex application domain which allowed me to improve the diagrams.
The domain diagrams became the necessary bridge between the business and technical people. Through the domain diagrams and their explanation, I could easily share the domain knowledge I gained while at the same time provided an easy reference for both technical and business staff.
Through the domain diagrams we manage to achieve:
- Created a common vocabulary for use by both the technical and business people,
- A deeper insight in the domain by the technical team,
- The discussions created a feedback loop through which technical limitations updated certain business assumptions,
- We established a better relationship between the business and technical teams which were located at separate locations, and this resulted in
- A shared ownership of the domain which increased team commitment and team optimism for a successful project.
Once the domain was understood by the technical team, a domain modeling session ensued which allowed us to achieve many technical goals and will be posted soon
Filed under: Agile, Teams — Aldo Cauchi Savona @ 1:42 pm
Earlier this week, I heard a comment by someone I was speaking to that they do not like Agile methods as they proclaim that the developers should not product any documentation or else, that there is no need for any planning. This was not the first time I heard this comment. One person exclaimed that when he worked in a company that used Lean practices, bad quality products were delivered thanks to the Lean practices they used!
Apparently, the people they worked with interpreted reduced documentation and planning for no documentation or planning. This gives rise to the view that Agile = Lack of Discipline = Bad Quality Products = Bad Process.
Anyone who has decided to dig a bit deeper into Agile and their theory would know that they are founded on two fundamental principles: Discipline and Quality. A great example where adequate documentation and quality driven development was used is the Boeing 777 project. Their aeroplane was ready for in-flight testing after 2 years of development, 3 years ahead of the norm.
If at the moment your team is not producing any form of documentation, or have a poor development development process, then when transitioning to Agile, you will most likely have to produce more documentation and do more planning than you currently do. When Agile practitioners talk about streamlining your documentation, they mean reducing the amount of documentation an existing cumbersome process might require. Again using Boeing as an example, the 777’s electronics specification document was over 2500 pages. When Boeing increased the collaboration with their provides, they could reduce their specification. The end result was that the 787 electronics specification document was reduced to 20 pages.
Agile methods ask all committed people to be more involved in the project, and to always act in the best interest of the project. This requires great discipline and dedication with the end result being a high quality product!
See: http://leadinganswers.typepad.com/leading_answers/leadership/;
Implementing Lean Software Development: From Concept to Cash by Mary and Tom Poppendieck.