Intro ¶
Whether you realise it or not, any non-trivial piece of code you write models a domain. Whether the model was deliberately designed and implemented or not, it is there. Its quality1, or lack thereof, shapes the future2.
Implicit domain models ¶
One of the results of writing code without a strong thought process are implicit domain models (IDMs). They’re are domain models that were neither deliberately designed nor expressed.
IDMs usually:
- emerge as a side effect of writing code with no serious forethought.
- model no more than our impressions and assumptions of the domain.
- have many gray areas when the behaviour is undefined.
- are tainted by primitive obsession and mediocre design quality.
- are costly to maintain and extend.
Implicit domain models are evil.
Remediation ¶
- Explicitly model your domain!
- Think first
- In code use types to represent your domain concepts3
-
By quality I mean: accuracy, readability, adaptability, and performance. ↩︎
-
It sounds a bit grand but it may often affect the code itself, the people involved, the project, the business, and eventually the customer. Every line of code you write has a cost associated to it. It is not merely the cost of your time. Most importantly it’s the cost of maintenance - reading, modifying, bug fixing, and extending. The more concise and meaningful your code is, the more efficient the further development process becomes. ↩︎
-
Make the compiler work hard for you. Using types correctly is like the fail fast principle - the code won’t even build if you try doing something illegal in your domain. ↩︎