In DDD it really important that everyone business people and developers share a model. A model is shared understanding of the system. It helps in forming a common language between all the stakeholders. This makes sure that the code design doesn't drift from the model and it reflects the domain.
The model has to be tightly associated with the domain it comes from. Designing without a model can lead to software which is not true to the domain it serves, and may not have the expected behavior.
One of the first things we are taught about modeling is to read the business specifications and look for nouns and verbs. The nouns are converted to classes, while the verbs become methods. This is a simplification, and will lead to a shallow model. All models are lacking depth in the beginning, but we should refactor the model toward deeper and deeper insight.
A model should be small enough to be assigned to one team.
A model contains the following:
Represent domain objects that are idenfiable with an id, and have a uniqueness. Like a Person, Customer, etc. The equality of
entities is based on their id.
Represent value containers, like street, address line1 and address line 2 can be combined into Address value object. They are place
holders for values. Two value objects with same values are considered equal.
Sophisticated domain models are seldom developed except through an iterative process of refactoring, including close involvement of the domain experts with developers interested in learning about the domain.
A bounded context is not a module, it provides the logical frame inside of which the model evolves. So bounded context encompasses the Module. Each Bounded Context should have a name which should be part of the Ubiquitous Language.
A Context Map is a document which outlines the different Bounded Contexts and the relationships between them. What it is important is that everyone working on the project shares and understands it.