Every software program relates to an activity of the user. The thing they apply the piece of software to is the domain of the software.
This could involve the physical world, like an airline-booking system, or it may be intangible, like a finance system.
An appropriate model makes sense of information and focuses it on a system.
A domain model is not a particular diagram, it is the idea it conveys.
It is not just knowledge, it is an origanised and selective abstraction of that knowledge.
Utility of a Model
There are three basic uses to determine the choice of a model:
The model and the heart of a design shape eachother.
The model and implementation share a link that makes the model relevant and to ensure enough care and attention went into it to allow it to represent a final, working program.
This also allows for easy maintainability and further development, as it is easy to interpret.
The model is a backbone of a language used by all team members.
Because of the binding I just mentioned, developers can talk about the program in the language used in the model without difficulty or translation.
Just talking about the model can be used to iterate on and improve the model.
The model is distilled knowledge.
The model is the preferred way of structure and prioritising elements of importance and interest.
The shared language and interest means team members can work together effectively, with early iterations being used to positively impact the subsequent versions of the model.
The Heart of the Software
The Heart of Software is to solve problems for the user. Every other feature is to support this notion.
The more complex the domain, the more skilled the team need to be to recognise this and carry out the task.
Instead of focusing om this though, individuals and businesses tend to focus more on technical skills and leave creating models to other people, rather than those who know the system.
The book uses an example of Monty Python and the Holy Grail, where a scene was shot over and over but wasn't funny, until the last take.
However, someone walked in shot, so the editor didn't use it as they were worried it would be percieved as an imperfection of their craft.
This wasn't resolved until a director demanded it be changed after the fact.
Similarly, leaders of a team creating a domain model can correct the course of a domain if it ever gets off track or too crowded.
Chapter One - Crunching Knowledge
The first chapter opens with an example of the author making a domain model centred around PCB design.
After lots of questions and iteration, understanding which parts were and were not important, a model was designed and code written based on that design.
It would allow any programmer to understand what would need to go into a program coding wise for it to work. This shows that iteration and understanding are very important, it allows for those designing the domain model to challenge their consulting skills, and allow the clients to learn how to communicate their ideas effectively.
Ingredients of Effective Modeling
Outlined are the things that lead to the success of the example's model:
Binding the model and the implementation.
A prototype was first created, creating the link between the two early, making it easier to iterate with no confusion.
Cultivating a language based on the model.
After some back and forth explaining what a domain model was and some basic PCB concepts, all members of the team could used language used and explained from the domain model and understand what eachother were saying.
Developing a knowledge-rich model.
The objects outlined in the model were used to break down and solve a complex problem, using knowledge from both the model designer and the client.
Distilling the model.
As the model progressed, more and more concepts were added to the model as it became apparent they were integral or important.
If a concept was not integral or important, it was removed or left out of the model.
Brainstorming and Experimenting
The language used, as well as the diagrams drawn were all turned into a small mock-up that were each judged and criticised. During each discussion, scenarios were brought up that challenged the model and encouraged the team to iterate and create a new model based on the feedback.
Knowledge Crunching
Good domain modellers take lots of information and filter out irrelevancy, looking to make the ideas presented simple and easy to understand, while also conveying the core information.
Success comes from one model being iterated upon many times, each time honing on those key concepts and refining them until they present the needed information without unnecessary detail.
This is performed by a team of people, taking in the information presented to them by clients and users of systems and models that already exist, by way of documentation or talking directly between both parties.
Prototypes feed into future iterations through the feedback observed.
The waterfall method was used instead of agile here, but the lack of feedback meant that knowledge was not transferred both parties, and the lack of iteration led to lacklustre products and no knowledge transferred between the two.
The iterative process was also used, but no knowledge was built up between each party as the process was abstract.
Experts describe a feature and they build it, with no feedback on the current build, just moving on to the next feature.
As a team works on a domain, their knowledge grows.
The developers need to learn more about the business they are helping, and the experts need to learn to narrow down their scope to essential components.
All this leads to an abstracted model, with deep understanding of the business and the project's requirements, as well as allowing itself to be easily iterated upon.
Continuous Learning
When writing software, the required knowledge to carry out the task is unevenly distributed between team members and documentation, and it makes writing that software harder as "we don't know what we don't know."
At the same time, people leaving the team or reorganisation means the knowledge is scattered again.
Typically, the knowledge isn't documented in an easy to keep track of way, and when the team is fragmented, so is the knowledge.
A productive team will continuously learn, with developers improving their technical knowledge, domain modelling skills and learning about the domain they're working in.
Knowledge-Rich Design
Business activities and rules are as important to a domain as the concepts explored and people involved.
Deep Models
As a domain grows and time passes, an element that was once thought necessary is sometimes discarded as it proves itself to be unnecessary after review and iterations.