Part of https://discourse.jujucharms.com/t/read-before-contributing/47, an opinionated guide by William Reade
Know What You Are Modelling
You’ve probably been given a description of the feature that describes a
subset of the desired UX, and doesn’t really cover anything else. This
is both a blessing and a curse; it gives you freedom to write good
internal models, but obscures what those models need to contain.
You’ll know the maxim “every problem has a solution that is simple,
obvious, and wrong”? That applies here in spades. There is information
that the user wants to see; and there is data that you need to persist:
and the two are almost certainly not actually the same, even once
you’ve eliminated any substrate-specific storage details. (I like to
point people at http://thecodelesscode.com/case/97 – but that really
only touches on the general problem.)
It only gets harder when you have a feature that’s exposed to two
entirely different classes of user – i.e. the things we expose to
charmers should almost certainly not map precisely to the things we
expose to users. They’re different people with different needs, working
in very different contexts; any model tuned to the needs of one group
will shortchange the other.
So, what do we do? We understand that whatever we expose to a user is
inherently a “view” (think MVC), and that what we model probably both
wants and needs to be a bit more sophisticated. After all, what is our
job if not to package up messy reality and render it comprehensible to
our users?