What exactly is the term "model" defined as in the context of Domain-Driven Development?

Question

I am reading "Patterns, Principles, and Practices of Domain-Driven Design" by Scott Millett and Nick Tune and so far it has been a great read (first 2 chapters read) but one term they seem to use a lot and appears to have a fairly abstract meaning is the term "model". They talk about developing a model using domain knowledge captured by things like Event Storming and Impact Mapping, but what exactly is a "model"? My best guess is its really the aggregation of your business model (rules and processes that business stakeholder see as requirements of the business) and your analysis model (logic and processes of the software itself) along with probably even more conceptual things, but I am unsure.

Could someone give me an example of what "defining your model" would mean in the world of DDD? Also, when the author says "model" I assuming he means "domain model"... but again I could be wrong.

Any clarification on what this is to any degree would be very helpful. Thanks

Answer 1

For Domain Driven Design, I find it best to start with Evans Domain Driven Design, and work from there.

To create software that is valuably involved in user's activities, a development team must bring to bear a body of knowledge related to those activities. The breadth of knowledge required can be daunting. The volume and complexity of information can be overwhelming. Models are tools for grappling with this overload. A model is a selectively simplified and consciously structured form of knowledge. An appropriate model makes sense of information an focuses it on a problem.

Later

In domain-driven design, three basic uses determine the choice of a model.

1. The model and the heart of the design shape each other....

2. The model is the backbone of a language used by all team members....

3. The model is distilled knowledge. The model is the team's agreed-upon way of structuring domain knowledge and distinguishing the elements of most interest.... The next three chapters set out to examine the meaning and value of each of these contributions in turn....

Answer 2

Your intuition is correct, the term "model" is very abstract. It is some form of "distilled knowledge" of sorts, but how that should look like, or what we actually mean by "model" or "domain model" (or whether the two are the same) depends very much on your context (project, paradigm, team, language, idioms, etc.)

Examples

In programming some people refer to the "data" as "the model" (you'll find plenty of these here on stackoverflow too). You know those UML diagrams, with classes and fields and relationships. This is sometimes referred to as "anemic object" "model". In my current project this is also referred to as "the business model".

Other people (myself included) would view classes and their behavior as "the model". This is sometimes called "rich domain model".

Some people suggest (including Eric Evans) that the model is "only" a (smallish) part of the application, and there are "other things" not directly related, such as Services, Repositories, UI, and other stuff.

Again, other people insist that "the model" as a whole is the application (such as myself and I believe David West for example).

So...

What I'm saying is, there is of course a meaning to the word, but it is not directly practical nor objective. You have to figure out yourself what the author meant by it, and it is entirely possible that next book or article you read will mean a different thing.