Introduction

To develop high-quality software, you have to know what that software is about. You cannot create a banking software system unless you have a good understanding of what banking is all about.

It’s not the software architect or the agile coach who knows about banking.

The banking system is well understood by the people inside, by the bankers. They know all the details, all the catches, all the possible issues and all the rules.

This is where we should start: the domain.

Building Domain Knowledge

Domain-Driven Design is to make software a reflection of the domain. Software needs to incorporate the core concepts and elements of the domain and accurately represent the relationships between them. The software has to model the domain.

If you’re working in an organisation with any kind of process, you likely have requirements expressed as a user story, task, or use case. These requirements or specifications you receive are usually incomplete.

Typically requirements are somewhat murky or expressed at a high level of understanding. In the course of designing and implementing a solution, it is beneficial when developers have access to the people who bring some expertise in the intended domain.

This is exactly the point of user stories, which are typically expressed according to a template like this: as a [role], I want [feature] so that [benefit].

Let’s take one example from the domain of insurance policy management: As an underwriter, I want approval control over a policy so that I can write safe exposures and reject risky ones.

Software developers are unlikely to fully understand the requirements that will go into delivering the supporting software based on this abstract description.

User stories, properly done, are an invitation to have a conversation with their author — the user. This means when you go to work on the approve/deny policy feature, you should ideally have access to an underwriter. Underwriters are domain experts who determine whether a certain category of exposure is safe for a carrier to cover.

Ubiquitous Language

When discussing the feature with your underwriter or whoever your project domain expert might be, pay close attention to the terminology they use. These domain experts use company- or industry-standard terminology. In DDD, this vocabulary is called the Ubiquitous Language. As developers, it is important to understand this vocabulary and use it when communicating with domain experts and implementing it in your code.

The Ubiquitous Language is a fundamental pattern of DDD. Although it may seem like common sense, consciously using the business language in code is essential for developers. This helps bridge the gap between business terminology and technical jargon, keeping the focus on delivering business value.