Implementing Domain Driven Design
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