Domain-driven design includes the idea of a “ubiquitous language” where the engineers and the domain experts and the product owners come together and agree on terminology for all the domain concepts, and the project then uses that terminology everywhere.
But on the projects I’ve been involved with, much more common is a situation where the requirements docs mostly use one term but sometimes use a different name for the same thing because the docs were worked on by two people who disagreed on the terms, the designers decide they don’t like how the words look so the UI calls the concept something else, the database developer reverses the term’s word order to fit their personally-preferred schema naming conventions, the API designer invents a compound name that includes both the UI and the database names, and so on. (I only barely exaggerate.) Which names map to which other names becomes tribal knowledge that’s usually not written down anywhere.
This kind of thing bugs me a lot, but I seem to be in the minority. I recognize that it makes very little functional difference, but it just feels sloppy to me and I don’t like having to remember multiple names for things. I will usually advocate for renaming things in the code for consistency, and other people on the team will almost always agree that it’s a good idea and will happily accept my PRs, but I’m usually the only one taking the initiative.
So, my question to you fine folks: am I wrong to care much about this? Do you think using consistent names for domain concepts across the board actually makes a meaningful difference in terms of code maintainability and discoverability? Or is the effort required to keep the names consistent over time actually greater than the mental overhead of working with the inconsistent names?
It’s very important, so that everyone knows that they are talking about the same thing.
Like, everyone needs to just agree to use the same term, while also not getting into bike shedding around which term to choose.
You’re not wrong to be bothered. Consistent naming is necessary for clear communication, especially since there is often so much abstraction in our line of work.
It does become difficult though when working cross-team or cross-service, because there may be overlap in terminology. You just have to do your best. In these situations, sometimes it helps to create a sort-of “glossary” for reference when needed.
you’re right, bro. It’s not just about naming consistency; understandable naming, not gibberish, is also very important. That is the key to precise communication. In my company, we are not allowed to use abbreviations to avoid causing any misunderstandings.
Consistency is very important espcially later on. When the user or client is talking about X and it’s called Z in the Database and Y in the code this will cause so much confusion. I think the fact you care means you are good programmer. Don’t loose that.
Is having a consistent domain language across the board important? Yes, obviously it’s a huge benefit in communication and in maintainability.
Is not following that convention, in and of itself, a huge problem? Probably not, so long as the primary parties understand the differences between separate aspects (such as the database using a different word order), although the documentation needs to explain this.
Is not being able to get an agreement on a consistent domain language that everyone will follow a problem for development? Yes. Huge. Crippling. It reeks of poor, indecisive management at the top project level, and petty interdepartmental squabbling all the way down. It’s a huge red flag as to a company’s ability to deliver. It’s not that difficult a thing to get agreement on or to enforce, as it’s entirely visible. If a project can’t do that, it’s not going to be able to do the things that are actually difficult.
