DDD (Domain Driven Design), I heard it some time around 2011 or 12 as a part of book club discussion. I went through the initial chapters of the book back then. Book felt very raw because of my inexperience during that time with the designs.
I got chance to view this video on youtube on What is DDD by Eric Evans, the author of DDD. I could now relate the pain of software design mentioned in the talk after two decades working in the field.
On the video timeline 1:22 , Eric says “when they look at some of the things we do, they say you know you don’t need all of that and truth and beauty. All that is needed is software that runs“. This is the part which struck with me the most.
If you ask people to think of a design given a usecase, they come back with tiers, layers, patterns and practices, backend architecture, front end patterns and all sort of technology aspects. They don’t see how the software is going to serve the customer or end user.
Just as an example, Eric started with a diagram for Cargo Routing service. Routing service which takes in Origin, Destination and CargoId and populates Cargo bookings table. That looked something like shown below.
Now the above view is technology view which is talking in terms of service, tables and requests. It is not a domain view.
Timeline 12:39 on the video discusses about creative collaboration of software and domain experts. Per Eric domain view or model is built during conversation with the people who are operating in the domain. In this case people who are dealing with shipping operations.
What I have seen in software development organization is that there is an intermediary group of people who act like a bridge between operations and software team. Software team is regarded as someone who will not understand the operations, and Operations/business are regarded as team which will not understand the technology.
Being the second hand information source, a lot of information is lost in translation. Sometimes, I have seen questioning a business or operations to understand the domain is treated like a taboo.
Although I see richness of DDD, I have not seen anyone asking questions in DDD way. I had been to workshops which lasted couple of days to a week at enterprise level, where most discussions happen around data sources and solving problems with existing design. Never had any discussions in a DDD way.
Ending Note
I use domain specific language while coding. Although variables and operations are named similar to domain language, what we can not do is identify the gaps in the design or mimic the real world operations. In my opininion DDD is meant to address that specific problem.
Technical Thoughts 