YAGNI… But, Some Things You Actually Will
Of course, your model will grow and evolve with your feature; don’t
try to anticipate every user request. Know that there will be changes,
but don’t imagine you know what they’ll be: just try to keep it clean
and modular to the extent that you can in service of future updates.
However, there are some things that you do need to do even if no user
explicitly requests them; and which are very hard to tack on after the
fact. Specifically: you must write consistent data to mongodb. This
is not optional; and nor, sadly, is it easy. You might be used to fancy
schmancy ACID transactions: we don’t have none of that here.
There’s plenty of documentation of its idiosyncracies – see
doc/hacking-state.txt, and the “MongoDB and Consistency” and “mgo/txn
example” pages on the wiki, not to mention the package’s own
documentation; so please read and understand all that before you
try to write persistence code.
And if you understand it all just by reading it, and you are not chilled
to the bone, you are either a prodigous genius or a fool-rushing-in.
Make sure that any state code you write is reviewed by someone who
understands the context enough to fear it.
Bluntly: you need referential integrity. It’s a shame you don’t get it
for free, but if you’re landing even a single branch that does not
fulfil these responsibilities, you are setting us up for the sort of
failure that requires live DB surgery to fix. “Usually works under easy
conditions” is not good enough: you need to shoot for “still acts
sensibly in the face of every adverse condition I can subject it to”, by
making use of the tools (SetBeforeHooks et al) that give you that
degree of control.