Filed under: Agile, Quality, Teams, Test-Driven Development — @ 10:12 am
During the transition phase from a tradition process to an Agile process, the word “Test” and it related activities, in my experience, always seemed to draw a heated debated between the developers and the testers in a company. Using an Agile framework, the test activities are drawn forward in time to the point where testing starts right from the beginning of software production. There is also the concept of “One Team”, where testers and developers are all “team members” with specialist roles, thus reducing the unpleasant “us and them” culture that was cultivated over the past years.
Test activities are drawn forward by bringing people with test and quality assurance knowledge into the scoping and estimation meetings and participate in the team all throughout the project. The main reason is that we are not only testing what is being produced, but the entire process (some of which we always do without noticing). We test the nature of the functionality, explore the customer and manager’s pre-conceptions, verify domain knowledge, check the validity of the design concepts, what is being produced and what has been produced in the past.
This topic has been discussed quite extensively online and here are some links to blogs, articles and discussions on the subject:
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