As a software developer, I had vaguely heard of the term “Domain Driven Design” thrown around in my office circle, but I never completely understood what exactly it is. In my quest to figure out what it was, I uncovered a video on YouTube by Eric Evans, who also basically came up with this concept in one of his books. This post is my attempt to list my takeaways from this video and my opinions on Domain Driven Design in general.
The Pitch
In the beginning stages of my career as a developer, I had a narrow vision when developing software. I saw the whole process as a version of “passing the buck” - the business folks would make some decisions and hand it over to the experience designers, they would design a user experience and hand it over to us devs, and we would mindlessly write code and pass it over to the QA peeps, all this done with no cohesion.
Due to this, our team would often run into problems. We would develop a whole feature only to end up with a disappointed client, because our development process was based on misunderstandings.
That’s where DDD could possibly have helped
The Approach
DDD aims to unify the language between development and business. The language of the domain should be the basis of modelling the software, since we aim to address the problems of the domain.
“Domain: A sphere of knowledge / activity”
“Model: System of abstractions representing selected aspects of the domain”
Understanding the domain is the most complex part of a software projects. So, it makes sense to have the domain as the core for the project, and build everything else on top of it, since “Architecture is the stuff that’s hard to change later.”
One of the main emphasis of DDD is the use of a Ubiquitous Language, which is to be used by all team members to connect all activities of the team with the software, within a bounded context. The idea is that if everything is structured around the language, there would be a lesser scope for misunderstandings
My DDD Encounters
After going through the video and looking up some articles, I realized that some tasks that I had worked on recently, could potentially have been us implementing DDD approaches. I had been using DDD to a certain extent, even without my knowledge!
One of the tasks was some refactoring we did. We moved around some files and folders and structured them based on their domains, since our team had subteams, each who owned a domain.
Another task was around the UI Design components we used. We had a UI library on Figma which consisted of multiple input/presentation elements like Text Box, Select Box etc. These would translate in to JSX Elements for us since we were using React, but the names we had for our React components were not connected to the names of the UI Elements, which would cause some confusion when we talked with our UI Designers. So the dev team took up the task of reorganizing the JSX Elements to name and organize them to what the domain dictated, so that it was in sync with the UI Elements.
DDD for the win
From what I’ve learnt and experienced, DDD definitely seems to be a powerful approach to software development. By placing the domain at the center of the design process, DDD enables developers to create software that is better aligned with the needs of the stakeholders.