Domain-Driven Design, part 2 — Model

All of us model every day. A friend tells us a joke, we imagine the situation and if we model it as is intended, we find the situation funny. A customer wants to have a new functionality and while he speaks, we try to imagine what does the customer wants — we model.

We are going to take a look at what is software modeling, how can we express the model and how can we capture key concepts.


The reality contains everything important, all details, everything we know and much more that is hidden. We are not able to describe the whole reality and describing it is not really our goal.

We can tell stories that cover important concepts of reality. We can convert the stories to use cases. We can express abstract models with diagrams and images — they are great to explain our abstract model.


Validation is usually a continuous process. As we deepen our domain knowledge, as we model and sketch the diagrams, experts are validating and correcting the abstract model immediately.

How to Get The Right Information

What is it? Whom is it for? We want to know our target group.

What are performance requirements? It’s a pretty big difference if a part of the software is used once in an hour or thousands of times per second. High-performance requirements can lead to a model with many trade-offs.

Asking the right questions is important in order to get the right information so we are able to model correctly. Asking the right questions is also the most difficult part of modeling.

Shopping Cart Story

In our e-shop we need a shopping cart. You know, a normal cart that is everywhere.

Ok, that is a good beginning, but can we explain what a cart is to a five old year child?

Cart… it is a box where you put products, like a barbie doll you want to buy. Sometimes you can also remove any item you don’t want to buy anymore because you found something better. The cart is not closed, you can always look at items you have inside. But unlike in the real world, the e-shop cart can always tell you how much everything costs together.

We keep a conversation in the real world, we ask questions and build mental, abstract model. The conversation would look really awkward in an article, so we just pretend it happened.

Use Cases and Constraints

  • Remove the product from the cart.
  • Show the cart detail.
  • Calculate the cart total price.
  • Change the product amount.
  • Once the item is in the cart, its price is fixed.

Key Concepts

The whole story is about a cart, the cart is definitely the central point. The cart is a box that holds items.

We can see the term product in all use cases, it is something that customers care about, something that they add to the cart. But in this story, we do not investigate what the product is, we assume that the product already exists in the system. We keep an eye on the cart.

Once we add a product into the cart, more interesting things happen. We start to call the product the item; the item is the product in the cart. The product has its price in the cart, and the price is fixed once the product is added to the cart. We need to hold price information. Since an item is a product in a cart, the fixed price is related to an item.

This is our abstract model.


Next time we are going to shape the abstract model into the implementation model.



Developer interested in Domain-Driven Design & Modeling