# 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.