Eric Lippert points out three things that I think apply in his article [future proofing a design][1]. I think if you follow it you will be in good shape.

> First: Premature generality is
> expensive.
> 
> Second: Represent in your model only those things which are always in the problem domain and whose class relationships are unchanging.
>
>Third: Keep your policies away from your mechanisms.

  [1]: http://blogs.msdn.com/b/ericlippert/archive/2009/01/16/future-proofing-a-design.aspx