title: MVC DDD and throwing errors for business logic
body: <p>I have read the book professional asp.net design patterns by scott millett and in his example he validates his business logic within a Validate() method and if any broken rules are broken they get added to a collection and the service layer calls a method on the model called GetBrokenRules().</p>
  
  <p>Now I have also read several books, blogs and forums regarding DDD and it says that in DDD an object should never get into an invalid state.</p>
  
  <p>All the examples I have seen regarding DDD throw errors when a business rule has been broken instead of passing back a collection of broken rules. I have even downloaded the latest source code by scott millett and he has now changed his code which now throws errors instead of passing back the list of broken rules. I have also seen the same approach with other DDD code samples.</p>
  
  <p>I am having a debate with a team member who believes that throwing errors is resource expensive and we should <strong>NOT</strong> throw the error but return a collection of broken rules like we currently do. However by doing this we are passing around an object that is invalid because it has dodgy data and we only check for its broken rules at the end.</p>
  
  <p>I was just thinking what other peoples opinons are on this subject. Should we throw an error as soon as a business rule fails? If so, can you highlight any pros and cons of doing so.
  I don't know how resource expensive throwing errors are in .net so I can not argue against that point but I was wondering if this is also a matter of personal opinoin instead of coding standards.</p>
  
  <p>Mike</p>