Ubiquitous language without domain-driven design
Shared team language, project dictionary, terms. In software development, we all speaking about business domain terms but rarely taking care about unifying our language between each other when talking about the very same things. As I am an independent software developer, I am switching projects in more or less one year period. In all projects, I am facing similar problems, and the biggest issue I am continuously fighting with is the absence of using ubiquitous language. The thing is that I am not an idealist about practicing domain driven design in all types of projects (there aren’t always green field projects in the world), but I believe that the ubiquitous language as was defined in Domain driven design by Eric Evans can (and should) be adopted in all the projects.
Software development is challenging, and one of the challenges of professional software development is that programmers aren’t necessarily experts in the areas of which they write software. When I started on these projects, I knew nothing about those things. After some years of experience, I have developed some sense to tackle new business domain even without sufficient materials but missing of ubiquitous language my biggest complaint before learning something.
Being on the same page
For projects which are in growing state (but basically for all) is essential to have a sharp learning curve for incomers. Being on the same page with all the types of members or influencers of that project helps to avoid mistakes, bugs and have a significant impact to the maintainability of produced software. The absence of ubiquitous language or project glossary is in my eyes strategic failure of most projects and leads to missed deadlines, buggy behaviour and higher cost of maintaining the software. Here is my list of specific symptoms of problems derived from missing ubiquitous language:
-
Developers are unable to describe parts of the business domain to the other developers.
-
There is more than one version of documentation used across project members.
-
Analysts are speaking about terms which are not included in a codebase, or there are slight modifications in names.
-
Analysts haven’t unified their language at all, and each analyst is speaking about the same thing with different terms.
-
Also, they disagree on concepts often, and they are wrong about some because they haven’t thought of every aspect before.
-
Documentation is spawned across huge documents or wiki pages where is easy to forget the context.
-
The codebase is a mix of framework designs, patterns, and business domain without clear borders.
-
Inside codebase are such classes as managers, processors or so.
-
There are existing mind maps inside brains of current developers about terms used by developers and by analysts.
-
Hiring programmers with expertise in a particular domain don’t help in expected amount and doesn’t eliminate problems at all.
-
About this hiring I would say, that better choice between a great programmer with no domain experience and a mediocre programmer with lots of domain experience is the great developer.
-
In the codebase are remaining old parts which are currently not used.
Kick-off of own Project glossary and contribution to the tracking system
When you see any of problems mentioned above, you have bad luck and need to absorb all the existing mental maps to have at least some picture about a business domain of produced software. It’s even harder because you aren’t expert in that business domain because you were working with others often. So what about kick-offing your project glossary just for memorising the given knowledge and after having something just publish for others? In my experience, this is very helpful and using your glossary in every discussion with an analyst or other developer helps to sharp terms and even helps as a reminder for others that something is smelling.
So you’ll create a glossary of terms with simple definitions. After several discussions (not directly speaking about terms) you’ll include the similarities for same conditions, historical terms. As you include definitions, you can’t help but develop reusable phrases for the language because you are forced to write in the language of the domain. You will discover which parts of the codebase are touching which business terms and attach those parts or even class names to the glossary as well.
After such a hard work you will have something for discussion with everybody - analysts, other developers, project managers. I can guarantee that if they see your effort, it will be hard for them to not taking into account the problem with all the mixed terms. Maybe you can also create some tickets, issues in your tracking system to rewrite this and that class or even fields, methods inside classes which would not mean efforts to tackle it.
In the most central principles, the domain driven design is about discussion, listening, understanding a business value. You can base this discussion on your project glossary and even invoke such debate in the project team.
In Conclusion
Ubiquitous language or project glossary with simple descriptions is the basement of every software project even you are not practicing other parts of a domain-driven design. We are, after all, a modelling business domain with our software. So project glossary is about reducing confusion and translation time. You can own kick-off glossary for yourself primarily, but it can happen that it can be central place maintaining by everyone after some effort. It’s hard to have patience with the tackling of all the difficulties maintaining of such document by yourself, but it will reward you with cleaner software, better work was done and decreased a probability of bugs introduction.
P.S. If you enjoyed this post, you could follow me on @mikealdo007 to stay in touch with my further articles and other thoughts.
P.S.2 Cover image by Patrick Tomasso | unsplash.com.