As mentioned earlier, a domain model objects represent data and behavior of the domain. By writing "objects", I don't mean anything related to object-oriented languages, but rather the essence they represent. Implementation of a domain model is also shaped by the programming language that is used so that such objects can be records, structs or, in fact, objects. Because this book is about using C# to implement Domain-Driven Design, we will be using classes and objects to implement our domain models. 

Even when we are equipped with the notion of polymorphism, so we can combine data and behavior inside our classes, this does not directly mean that our domain model will include such classes. Everything that is part of the domain implementation is also part of the domain model. There is no better documentation for the domain model than the code that implements such a model.

Behavior and data in the model are interconnected. The behavior of the model has no other meaning than to manipulate the model data and since the data represents nothing else than what the model is interested in and operates on, such data is also known as the state. The state is the data that describes how our system looks like at a particular moment in time. Every behavior of the model changes the state. The state is that thing we persist to the database and that we can recover at any time before applying a new behavior.

It can be illustrated by a simple example:

Here you can see the account balance as a piece of state. When we apply some behavior, the state changes. It is called state transition. Each domain model behavior causes a transition for the domain model state. Everything that documents how the domain state changes, should be a part of the domain model.