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?
This might be the most sane take in the this thread.
Yes, ideally it would all match up but I’ll reject PRs that want to rename a bunch of files/fields/properties/columns/etc because marketing/business want to call it something else. Also you have to pick your battles, sometimes it’s just not worth fighting it.
We have some things that were named badly on the backend a decade or more ago, in our API we name them correctly (example “qty” on the backed, “quantity” in the API). We will NEVER go back and change the old name, it’s not going to happen. It would take a massive effort for no real gain.
Also parts of our API are (semi-)publicly available and so we take that as an opportunity to rename certain things for “public consumption” because we call something different internally (with justification) but there is no good reason to make external people learn our internal lingo/concepts.
Lastly I’ve learned over the last 15+ years in the industry that just about every “black and white rule” is a bad one. You shouldn’t have a slavish devotion to a rule just because it is a “rule” that someone slapped down at some point. It’s like the REST purists who bitch and moan about “that endpoint isn’t RESTful”. Get out and write some real software with real business requirements then get back to me.
I’m not saying rules are bad and I believe heavily in the “Chesterton’s fence” concept but you also have to know when to break the rules instead of twisting yourself and your code into a pretzel to stay within the “letter of the rule”.
I know your point is that people should use real judgement, but that’s a great line to draw for people who need it.
Is naming consistency important enough to break compatibility? No, absolutely not.