In the hart of domain driven design is ubiquitous language. Everyone involved, from developer to domain expert, speaks the same language. This should not be just a matter of using the same labels for "things". Many a discussion starts with the question how to name something and leads to a shared analysis of what that thing really is. In the end (of that discussion) the resulting name is well chosen and has a deeper meaning.

But when it comes to naming things in the domain of software development I often see a not so ubiquitous language. To name just two of today's hobby horses: both the IoC/DI label and the TDD/BDD label are used for a diversity of "things". IoC and DI are not quite the same thing. But when it comes to naming techniques, designs, architectures or frameworks all to often the full label IoC/DI is applied. This almost reads as IoC aka DI, suggesting two different names for one and the same "thing". Whatever that thing is. It could be a framework implementing an IoC container or a design decision to use the DI pattern. Good articles on the subject describe the similarities and the differences between DI and IoC. Only the best take it a step further and use one name for one thing and suggest clear names rich in meaning for all other things.

The same story more or less applies to TDD/BDD. On the bright side Matthew Podwysocki just published a very good post on defining BDD as compared to TDD. So next time you read the label TDD/BDD just read that post again. And don't get me started on naming products. Microsoft almost makes a habit of names like "WCF formerly known as Indigo". I've been ranting on that before.

The domain of building software is one of the most complex domains you can imagine. Imho it would be beneficial to everybody to be as clear as possible in naming things here. What works for our customers will work for ourselves as well.