Naming things is hard. I still get it wrong after a decade+ of building complex systems. Naming things is also very important. Having some common language or w

Naming things is hard. I still get it wrong after a decade+ of building complex systems. Naming things is also very important. Having some common language or way to refer to the various abstractions in the business is essential for basic teamwork. Even if the name is a cringetastic take on a comic book character. As long as everyone agrees on the string literal, you will be able to make forward progress. If you aren't absolutely certain what something should be called (i.e. maybe you are prototyping a crazy new idea), just invent some crap to keep moving along. I've got a shitload of odds and ends in static classes simply named things like "Utility" and "Hack". When you aren't so invested in what something is called, I have found you are much more willing to get "creative" with it. Naming things can also start to imply some sort of structure, so keeping it flat like this helps reduce the cognitive load. On the other hand, maybe you should consider more precise, deliberate naming if the business at hand is relatively stable and complex. Banking is a great example of a domain where very precise type names can make a huge difference in productivity. There is a gigantic difference between a "beneficial" owner and a "beneficiary". Applying reductive/creative naming schemes to this domain would likely cause more harm than good. You can always rename stuff in the future. Even database schemas can be migrated over time without impacting live customers. You can even rename an entire company (i.e. Facebook => Meta).