- since 3nf captures most business rules, each subsequent denormalization that you may do should be countered or linked directly to a piece of code that implements the business rule that was lost during the denorm process. It'd be supercool if there was a way to document that in the code/model somehow.
successful normalization requires that you understand your business, whereas successful denormalization requires that you understand the runtime nature of your service (reporting, metrics, partitioning, performance, etc).
it's easier to backfill into a simple, crisp model than into a "flexible" model that probably doesn't work anyways and may be full of incorect business rules. Resist the urge to put random opaque fields (or arbitrary key/value pairs) into your data model.
Having worked almost exclusively on framework-level code, I haven't had to do much modeling of business problems. So I learnt a lot.