In my experience, ubiquitous language is the “core subdomain” of domain-driven design. The ability to speak the same language with our domain experts has been indispensable to us. It turned out to be a much more effective way to share knowledge than tests or documents.

Moreover, the presence of a ubiquitous language has been a major predictor of a proj‐ ect’s success for us:

• When we started, our implementation of the marketing system was far from per‐ fect. However, the robust ubiquitous language compensated for the architectural shortcomings and allowed us to deliver the project’s goals.

• In the CRM context, we screwed it up. Unintentionally, we had two languages describing the same business domain. We strived to have a proper design, but because of the communication issues we ended up with a huge mess.

• The event crunchers project started as a simple supporting subdomain, and we didn’t invest in the ubiquitous language. We regretted this decision big time when the complexity started growing. It would have taken us much less time if we ini‐ tially started with a ubiquitous language.

• In the bonuses project, the business logic became more complex by orders of magnitude, but the ubiquitous language allowed us to notice the need for a change in the implementation strategy much earlier.

Hence, ubiquitous language is not optional, regardless of whether you’re working on a core, supporting, or generic subdomain.

We learned the importance of investing in the ubiquitous language as early as possi‐ ble. It requires immense effort and patience to “fix” a language if it has been spoken for a while in a company (as was the case with our CRM system). We were able to fix the implementation. It wasn’t easy, but eventually we did it. That’s not the case, how‐ ever, for the language. For years, some people were still using the conflicting terms defined in the initial implementation.