2. Domain-Driven Design – Ubiquitous Language
When we design a new system, it's critical that everyone clearly understands the domain and the business problem we're trying to solve. The first step towards this goal is to establish a common language that everyone understands. This language should be rooted in the terminology used by the domain experts and your customers. In DDD, this is known as the Ubiquitous Language because everyone on the team should be using it.
How can we start building the ubiquitous language for the trading system we're designing? Let's start with an example. Assume that John's brokerage account holds 1,000 shares of Apple and 2,000 shares of Tesla. This is shown visually below.
This example suggests that a Brokerage Account can hold Positions in multiple Securities. The highlighted words in the last sentence are well known terms in the trading domain. Let's add them to our ubiquitous language. Furthermore, we will show the relationship between these terms using a diagram known as the domain model:
The domain model shows three terms in our ubiquitous language (Brokerage
Account, Position and Security) as boxes. These boxes are connected using lines
called relationships. The relationship between Brokerage Account and Position is
a zero-to-many relationship denoted by the 0..*. The way we read it is as
follows:
A Brokerage Account is associated with zero or more Positions.
Similarly, a Position is associated with exactly one Security. We'll discuss the domain model notation in more detail in the next section.
We discover new terms in the ubiquitous language by talking to domain experts and our customers. Here’s a hypothetical conversation between a software developer and an investment advisor at our brokerage firm. The investment advisor is our domain expert. We'll highlight terms that are commonly used in the trading domain.
As a result of this discussion, we can update the domain model to include this concept of Lots:
The domain model uses the Ubiquitous Language to provide a rich, visual view of the domain. It provides the precision needed to implement the business requirements correctly. Domain experts don't need to understand domain diagrams and the details of the notation. However, they should understand the language behind it. After all, that's the language they use every day! It's the project team's responsibility to translate that language into a domain model and agree on what it means. This includes product managers, designers, engineers, QA, and other disciplines involved in the project.
The next section explains domain models in more detail and how to construct them.