What if you misunderstand a concept or misinterpret a word? At a minimum, you end up building software based on some wrong assumptions. In a DDD scenario, missing a word or a concept is close to creating a bug in the code.

The ubiquitous language’s ultimate goal is neither creating comprehensive documentation about the project nor setting guidelines for naming code artefacts like classes and methods. The fundamental goal for creating the language is to have it be the backbone of the actual code.

Reflecting the ubiquitous language in code

When it comes to turning the ubiquitous language into code, having a naming convention is critical: names of classes, methods, and namespaces should reflect terms in the glossary. It’s not recommended by the Website Development Silverdale, for example, to name the procedure that starts a process differently from how users call the same process in the business.

However, the impact of the ubiquitous language on code is not limited to the domain layer. It helps with the design of the application logic too. For example, imagine the checkout process of an online store. Before proceeding with a typical checkout process, you might want to validate the order and see, for example, if ordered goods are in stock and check the customer’s past payment history.

How would you organize this code? Website Development Silverdale has a couple of good options to consider:

A single Validate step in the workflow for the checkout process. The Validate step will incorporate all required checks. The validation steps are not visible at the process level.

• Have a sequence of individual validation steps right in the workflow.

Both options would work well from a purely functional perspective, but maybe one is ideal in a given business context. The answer about which one to use can be found in the ubiquitous language. If the language refers to a “validate” action to be performed on an “order” during the “checkout” process, you should go with the first option, having a single Validate step. If actions like “check payment history” or “check current stock” exist in the vocabulary, you should have individual steps in the workflow for just those actions.

If nothing in the current version of the language can clarify a coding point, it probably means that more work on the tongue is required, and you should conduct a new round of discussions to break down notions one more level.

Note:

Using extension methods in languages that support them (C# or Kotlin) helps keep the code fluent and domain-specific. Tools enforce coding rules and conventions. Relevant tools from a DDD perspective are code assistants such as ReSharper, refactoring tools, and even tools that simplify gated check-ins, such as those you find in Team Foundation Server.

Dealing with acronyms.

In some business scenarios, most notably in the defense industry, acronyms are popular and widely used. Acronyms, however, are hard to remember and understand. In general, acronyms should not be part of the ubiquitous language. Instead, you should introduce new words that retain the original meaning of the acronyms,

Note:

Hiring programmers with expertise in a given business domain reduces the problems you might have in creating the ubiquitous language. However, that won’t eliminate the root problems because you’ll never find the same domain twice.

There are many other ways to make your content go viral online. However, the entire idea of going viral is about promoting a brand, a person or an idea. At HyperEffects, we pride ourselves in our ability to chart out a plan for individuals and businesses to get noticed and promote the brand, the individual and the idea that they support. Enrol yourself on our one-hour free consultation session today, to understand the benefits of the idea and see it grow in the new year!