As we discussed in Chapter 1, Why Domain-Driven Design?, the software we design and implement has only one primary purpose—to solve a domain problem. Understanding the problem space or the business domain is crucial for the journey of finding proper solutions and satisfying users with the systems we make. When we get more understanding about the domain using techniques such as Big Picture EventStorming, as discussed in the previous chapter, we need to go a bit deeper and try visualizing our knowledge using visual artifacts that other people would understand and will be able to reason about. In short, we need a model.
Domain model
What does the model represent?
There are many different things described by the word model...