Have you ever made changes to a piece of code and then experienced an unexpected change somewhere else in the software? Have you ever had a misunderstanding with a customer? Maybe you both thought you were on the same page, but in reality you were talking above each other’s heads? Have you ever solved the wrong problem? Typically highlighted through the customer’s confused expression as she utters the words «but that’s not what I asked for!».
Yeah, you get the point. If you have some years under your belt as a software developer, chances are that you have been through these fun little experiences quite a few times.
I say, let’s turn our backs on the computer – and face the domain. Yes, that means we have to stop coding once in a while, and instead learn about tax return, exports of seafood or whatever domain our customers have business in. And that may seem boring to some, but it’s really important. So think about what motivates you; what drives you when you get up in the morning and go to work (except the morning coffee of course)? Maybe you’re looking forward to refactor that piece of sh** code (pardon my french) you wrote two years ago? Maybe you can’t wait to try out that new framework?
Software is a powerful tool, and it can help us enrich people’s everyday lives.
And maybe… maybe you look forward to making a difference? Because that’s what we do. Software is a powerful tool, and it can help us enrich people’s everyday lives. It can improve food safety with smileys. It can help you find the information you need when you need it the most. And it can even save lives.
Unfortunately, the reality is that most businesses today sees IT as an impediment. IT projects keep exceeding time and budget, and some just fail completely, wasting millions of dollars. Even those projects that do make it through to the end, often delivers limited business value.
[Software engineering] was focused around computers and code, and the user and the domain rapidly received far less attention.
In the 1960s however, software was more commonly seen as a strategic advantage. In these early years of software development, the end users were the ones writing code. A banker would build software for use in banking, and a healthcare professional would build software for use in the health industry. The resulting products would give businesses a competitive edge, because it was made by people possessing knowledge of the domain – the domain experts. As the demand for software developers rose, the profession of software engineering was born. It was focused around computers and code, and the user and the domain received far less attention.
Knowledge of the business and business needs is key to delivering value. Without it, the code’s design will not be aligned with the business, and as a consequence, it will be difficult and time consuming to maintain and evolve over time. Also, if we, as developers, don’t understand the domain, it will be hard to come up with solutions and create software which benefit and enhance the business – regardless of how elegant the technical solution might be.
This has been recognised, and through the years there have been many attempts at turning the focus back on the domain; object oriented programming and extreme programming being amongst them. In 2003, Eric Evans coined the term Domain-Driven Design (DDD), which is yet another attempt at bringing the main focus back on understanding the realm of the problems you are trying to solve – the domain.
[Domain-Driven Design] will assist us in fostering digital excitement through user-friendly software that solve real business needs.
DDD is not a new shiny object for developers to chase; it’s a structure of good ideas from a bunch of smart people through the years, enabling us to communicate about the challenges we have. In essence, it’s about turning our attention to the domain, and collaborating with the domain experts to really understand the business and the business needs.
My claim is that practising DDD, or rather the ideas DDD is composed of, will lead to fewer misunderstandings and more valueable and maintainable solutions. It will assist us in fostering digital excitement through user-friendly software solving real business needs.
It may then come as no surprise that, in my opinion, an increased focus on the domain, and in extension the user, is the missing piece of software development today. And I truly believe that DDD has the right tools to get us back on track.
Did I pique your interest for Domain-Driven Design? For further reading I recommend this free booklet (filled with illustrations), Vaughn Vernon’s book Domain-Driven Design Distilled, or, you know, just googling it.
The inspiration for this blog post is DDD Europe 2017, especially prof. David West’s talk The Past (1968) and Future of Domain (driven) Design, and my own experience practising and reading about DDD over the last two years.