"Speak" your architecture: From domain language to well-named components

Naming is hard. Teams who write software often give rather technological names to the components they write. This is a problem because it makes the system less understandable and more difficult to extend.
I propose to show more respect to the language that the users and other domain experts speak because it will allow us to think as they think which will make our software more compatible with the users' mental models.
Let's call the modules, components, interfaces, services and entities as business-friendly and technology-neutral as possible and use some patterns from Domain-Driven Design to achieve an architecture that is well-structured, easy to explain and maintain over the years. It's a matter of attitude and attention, folks!