Model Play-book
A model is a central component within any application. This model decides what your view is on the outside world. As such, it effectively makes or breaks your application (your business rules can change, but if your view on the outside world fundamentally changes, you're effectively caught with your pants down, and that's embarrassing! To be honest though, this is rarely where applications fail, because such models are often conceived with enough knowledge to do this properly.
Where applications do tend to fail is not so much the model, as much as the meta-model. Where a meta-model is a model we use to describe our other model, the one that matters. A meta-model describes the set of rules that govern how an application works. There are a few ways a meta-model fail, the most common one is a general lack of a play-book or rule-book. The set of rules that govern what something in your model should look/feel like: http://en.wikipedia.org/wiki/Metamodeling
Time for something more tangible. Let's look at Java, within Java, you have objects, these objects have state and behaviour. More specifically, Objects are instances of classes that (statically) define fields and methods. Within the Bean-spec we define two special methods that expose a field, a getter/setter (or accessor and mutator respectively), this getter and setter gets and respectively sets a value to a field, something any Java developer should be familiar with (if only because of the auto-generation functions any IDE has). This is effectively our meta-model to our meta-model. This extra layer of meta-model gives you a lot of room to define a lot of things. Within the JPA spec of Java, a specific meta-model is defined called the entity-model. This entity model has some rules that govern how JPA handles 'something' in it's model, more on this here.
You'll find that the following can (and will happen) with a poorly defined or inconsistent meta-model:
- Mutually exclusive fixes: fixing one part of the model breaks other part of the model, and vice versa: Using a utility to solve a problem proves to be incompatible with all your problems.
- Any changes in the model causing a lot of regression issues: having to reinvent the wheel over and over again: Redefining what your utilities are able to do again and again, having to adapt everything you already have,
- Copy-paste-code/issues: Having to repeat incomplete parts of the application to do the same thing over and over again, replicating bugs in the process: Instead of having a generic utility, making the same mistakes over and over again, having to fix them in many places when you fine them,
- Long turn-around of trivial issues: having to reinvent the wheel over and over again, Endlessly extending your utilities endlessly and making them spaghetti,
- Repeating work: having to do the same type of modifications very often, this is usually fixed with frameworks that do similar things: Not being able to reliably build generic utilities.