“Any fool can write code that a computer can understand.
Good programmers write code that a human can understand.” - Martin Fowler
In our “Mind The Gap!” series we have been attempting to elucidate the matter of miscommunication between management and engineers, a matter that has been causing trouble to the majority of modern organizations. In previous articles, we have identified some management styles that can impede the flow of communication in your company, as well as types of developers to be careful of, as they may be too tough to handle. However, jokes and memes aside, every problem has a solution and in the following paragraphs, we will examine the concept of Domain Driven Design, a discipline that promises to improve the quality of communications between the stakeholders of your projects and thus improve your overall efficiency.
The term and the idea behind Domain Driven Design were first introduced by Eric J. Evans in his book Domain - Driven Design: Tackling Complexity in the Heart of Software which stills acts as the blueprint for this software design & development paradigm. Evans, being an expert software designer himself, witnessed one major difficulty that many organizations have been dealing with; great software with great code that failed to adjust to the specific needs and turbulences of the industry (aka the domain).
But, ultimately, is that valuable software?
Probably no as quality software, software of value, cannot and should not be built in a vacuum with some great lines of code. It has to take into consideration every aspect of the domain that engulfs it and the issues of which it has been created to solve. For less complex domains, one could very well design and develop working software that provides value to the user without diving deeper into the industry’s darker secrets but, for more complex ones, a domain expert’s opinion is necessary; you wouldn’t build a software for a financial institution without knowing the ins and outs of the industry, would you?
Therefore, it comes as a no-brainer that, before working on an application, software developers and software designers have to be in constant communication with the domain expert, whoever that may be for the given project (product owner, project manager, client), and this is where most teams falter as the two parties can hardly understand each other.
Given that management and developers speak in different terms, using different abbreviations and their own jargon, it comes as no surprise why the meetings between them end in frustration and add more questions than answers. Therefore, Evans proposed a solution.
Among the many principles, the Domain Driven Design method encompasses, Ubiquitous Language is the backbone of the model. Put it simply, domain experts and technical experts need to apply a set of standards for communication, in terms of words and terminologies, that will be used by every team during both the design phase and the development process of a software.
Starting with designing the actual model, every class, object, and service, should be named using nouns and/or phrases that make sense both in the context of the domain and of the software. Developing a common ground in communications, in this stage, by setting up a glossary document and then enforcing the use of that glossary in your everyday dialogue is paramount to the success of the overall project.
Effective and streamlined communications will save you time and costs and will improve the quality of your teams’ deliverables (especially in Agile environments) so consider investing as much time into that glossary, as you would invest into naming your D&D character.
Domain Driven Development
Framing and defining your model’s entities and value objects using a commonly accepted language between management and development should be step one, step two being using this set of communication specifics in every meeting and stand up. Then there’s step three.
The very same methodology of Ubiquitous Language should be applied to the software’s code as well. Not only because this would help meetings about bugs feel shorter and provide more value and information but also, it would help with keeping your code clean, efficient and readable by every stakeholder involved.
Therefore, your source code would be more easily maintained through time and any strategic changes or alterations to the model itself will reflect in the code in a matter of hours.
Not to mention that implementing new features, would be a breeze and would make your developers feel like they are assembling a puzzle for 4-year-olds.
For more resources on the subject of Domain Driven Design
- The book that started it all: Domain - Driven Design: Tackling Complexity in the Heart of Software by Eric J. Evans
- An excellent shorter version of the Evans’ book: Domain Driven Design Quickly
- Eric Evans’ keynote at Explore DDD in Denver(2018): DDD Isn't Done: A Skeptical, Optimistic, Pragmatic Look