This post originated from an RSS feed registered with Ruby Buzz by Eric Hodel. Original Post: WTF: The Mythical Business Layer Feed Title: Segment7 Feed URL: http://blog.segment7.net/articles.rss Feed Description: Posts about and around Ruby, MetaRuby, ruby2c, ZenTest and work at The Robot Co-op. Latest Ruby Buzz Posts Latest Ruby Buzz Posts by Eric Hodel Latest Posts From Segment7

Worse Than Failure made a post a few days ago about, among other things, built-in complexity, especially where its unnecessary and unsuited for getting things done.

Just look at the dreadful specs we’re given to work with:

When a Sale is Cleared, only Managers with Void Approval and Executives may issue a Cancellation Request. If the Propagation Status for the Transferable Receivable is not Pending and the Expense Allocation Type is Reversible, the Cancellation Request is issued for Processing; otherwise, it is issued for Approval.

I’m sure those of you who managed to make it through that spec did not have visions of IF-ELSE code blocks swirling through your head. I’ll bet some of you, without even seeing the rest of specs, excitedly envisioned a CancelationWorkflowProvider that inherited from the abstract RequestWorkflowProvider and implemented the IPermissionRequired, IPropogationStatusRequired, and IExpenseAllocationTypeRequired interfaces, and was powered by the all-encompassing WorkflowManager. Why? Because that’s so much more challenging than writing a simple IF-ELSE code block.

—The Mythical Business Layer via Worse Than Failure

While the post focuses on the “business layer” of an application, it is applicable to any development. There’s no need to write that extra library! Start with the core of you want to do, and grow, then refactor, then grow again. Reuse what already exists unless it can’t be molded to your will. If your application code gets too big pull a library out. Don’t write the library up-front, you don’t need it and you won’t need it.