Member-only story
OPINIONATED
7 Programming Rules of Thumb
Remember them, and you’ll create better software
I’ll just cut right to the chase. No introduction needed.
1. Steer Clear of Primitive Types.
Look at this method WithdrawMoney(string accountIban, decimal amount). In a (European) financial system, you’re dealing with IBANs, which is a plain text string looking something like this DK5000400440116243.
Despite being purely text, some stringent rules govern how IBANs are constructed and validated.
Simply using a string type is communicating to the world — anyone using your code — that any text whatsoever is completely OK to pass in.
This is obviously wrong.
A much better approach is to capture the domain knowledge in a special class and verify that it’s actually in a valid state. The code is as follows:
Sure, it’s more code, but the number of code lines has never been a great metric to determine if the software is good or bad. The number of classes is neither a useful metric.
If you’re a visual learner, feel free to watch this youtube video where I also explain how you can avoid primitive types in your models.
2. No Public Setters.
In domain-driven design, you usually don’t think in terms of simply updating or reassigning a value. You’d, for example, say that a user “changed” their username.
Public setters are essentially saying, “Set my values to whatever you’d like. I don’t care to what or even why.”
The what and why are equally important. While you can often guard against invalid values, you can’t express why a value is changed if you’re using a public setter, or setter method. Here is the code:
