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?
You must log in or register to comment.
It’s a symptom of a general lack of respect and lack of desire to collaborate with one another. Compared to real problems you’ll face in trying to communicate and collaborate towards a goal, it’s a miniscule level of effort required to get on the same page with what things are called and then roughly stick to it going forward.
Is the difference in naming going to make a difference? Maybe. The little extra bit of cognitive load and confusion that can result may or may not hurt, although it definitely won’t help. How about the lack of shared desire to put in the effort that it takes to operate as a cohesive unit; is that going to make a difference? Yes, yes, a thousand times yes.
It may or may not be something worth stressing over or trying to fix on your end (sometimes it just be that way), but it’s definitely not unimportant.
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.
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.
Yes, that is the single most important lesson from DDD.
If you work in a large place, naming coherence (that comes from conceptual coherence) is one of the most impactful things for you effectiveness. It will save you from writing useless software, from surprise requirements changes, it will increase the target public of any software you create, and so on.
The problem is that you just won’t get it. There is no task or process you can do that leads you there. What you can do is improve it here or there, a little bit, at great cost. So, I’d say, do insist on it, but pick your battles. You can’t really win, so if you focus on it you will burn yourself and your image out.
I think I’ve learned to get less attached to opinionated terminology in code and database design because I see it happen all the time where the usage of the value/field/thing can evolve naturally over time as the business needs evolve. And refactoring field names (as an example) from UI to database is often a painful exercise, not without significant regression risks. (Depending on the size and complexity of your systems, of course)
So while I totally agree with you and others that ideally naming would be consistent throughout, my real world experience with the issue has taught me that this isn’t the hill I die on.
My 2 cents from 10 years experience in the industry.
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.
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.
We recently had this issue at work with the term tenants.
We had tenants as in guests, tenants as in multi tenant backend and aad tenants.
It was beginning to get very confusing when talking about them so we sat down and came up with a list of terms we all agreed on.
I think it really depends on how the company is organised and who is working closely together as to whether it makes a big difference.
Different teams can use different names as long as they know what the others are meaning.
Anything to do with naming is going to be doomed to bike shedding (https://en.wikipedia.org/wiki/Law_of_triviality). The only way to avoid the kind of problem you mention is to have one person come up with all the naming rules and to enforce it.
You’re right to think it’s important because it’ll make maintenance significantly easier than having 3-4 disparate naming schemes. However, there’s no way that you can get a group of people to agree on a single naming scheme. Everyone will have their own idea which will make complete sense to them but to no one else, and they’ll argue for hours about this. There’s no easy solution, even though it should be trivial.
I build software that is used by nearly all engineers in our company. We own hundreds of web applications and websites. We’ve grown by acquisition of smaller companies, and we have an extremely heterogenous environment.
25 years ago, I started my career as a web designer. Today, I’m a Principal Cloud and Platform Engineer. Still to this day, I regularly leverage lessons when building tech that I learned from the world of UX.
“Design is not how it looks. Design is how it works.” — Steve Jobs
Naming consistency helps to reduce the mental friction that people have when learning how something works. For example, one my projects is a suite of Terraform modules that are designed as building blocks which cover all of the fundamental pieces of any app’s stack. We have designed these 20-ish modules to work well standalone, as well as when used together. Certain patterns are the same across the board.
(1) We strongly favor dependency injection, and limit the use of ternary statements. In the world of Terraform, this is via variables or a .tfvars file. Everyone knows that this is how it works, so it reduces the mental friction when adopting a new/additional module.
(2) Variable names which do the same thing are named identically across all modules. Their descriptions are identical. For example,
tags = [k:v]works exactly the same way across all modules, and people don’t have to think about it.(3) Modules have a naming pattern. Among other things, they begin with the name of the service that the module talks to. (If we find that we’re talking to multiple services, we need to break the module down into smaller chunks.) So
aws-ornewrelic-ordatadog-orgithub-orpagerduty-are all examples.This overall “design” has not only helped reduce mental friction and made the modules easier to understand and use, but it also makes them easier to manage across hundreds of repositories supporting hundreds of apps. Collaboration, cooperation, and communication are all improved as a result. And if something is difficult to understand, then it means that we screwed up. We need to do a better job listening to the app-engineering teams and SREs who support them to streamline and clarify as much as possible.
“Customers” come in all sorts of shapes and forms.
It is warranted, and your colleagues seem to agree.
and other people on the team will almost always agree that it’s a good idea and will happily accept my PRs
I think you may be misinterpreting what is happening.
Them not taking initiative does not correlate to its importance. It’s just that most people don’t take initiative - or at least here, evidently, for naming consistency.
How much of an issue ambiguous naming is or may become depends on context - on a lot of things. But ambiguity in naming, just like elsewhere, weakens certainty and reasonability. If you can define and keep clear terminology, then always do so.
