Peeling and Slicing the Onion
The Model's job is to organize and store the application's data. That data might be a folder of emails, a document, a high score, or a set of invoices. The most important quality of an application's Model is its conformity to the real-world items it's describing. And your job is to give your team members the real-world insight they need so they can build an intuitive Model that faithfully and usefully describes its real-world analogs. You don't need to design the Model yourself, but this section should give you some insight on how to peel back the proverbial onion and model your data.
The Model needs to balance simplicity and robustness. Again, the easiest way to think about simplicity is in terms of reduction: Could you take anything out of the Model and still get the same functionality? Keep in mind that the users don't need to see everything in the Model because Views deals with displaying the contents of the model. But the Model's complexity will drive development and maintenance cost. Complexity will ultimately restrain your long-term flexibility. The best way to think about robustness is in terms of the various tasks you want the application to perform and how well it can perform them. Is it flexible enough to do whatever you want? You'll probably find you're frequently working to balance robustness and simplicity. For example, you'll often find yourself asking whether the additional complexity that a new feature would require is really ...