Here’s one for the software developer in all of us:

“It’s absolutely critical … to not think of these layers as persistence, business, and presentation. Database, processing, and user interface are much more appropriate terms.”

[I]t’s completely infeasible to encapsulate an application’s business logic into a single layer. It’s also logically impossible.

By the time a developer creates the perfect persistence layer — something that takes in any type of data, tucks it away somewhere, and provides an easy mechanism to retrieve it — he has created a separate infrastructure application. Recreated, actually. The operating system’s file system already does exactly that.

By the time a developer creates the perfect presentation layer — something that takes in any type of data and displays it in a flexible manner — he too has recreated an infrastructure application. ASP/PHP/etc with HTML already does a fantastic job of implementing that goal.

There is absolutely nothing wrong with having a multi-layered application. In many cases, anything but that would be a bad design. It’s absolutely critical, however, to not think of these layers as persistence, business, and presentation. Database, processing, and user interface are much more appropriate terms.

- Alex Papadimoulis @ Worse Than Failure: Link.

Big Ball of Mud

“Complete rubbish” sums it up nicely.

There’s a pattern for this recommendation, and it’s very common — The Big Ball of Mud.

- Comment @ WTF: Link.

Business Logic: the Junk Drawer

The business layer is not mythical, it’s simply done poorly in most instances because most development departments have no definition of what is business logic and what is presentation logic or database logic.

When I separate, I ask myself what I am doing in a class. If my class exists only to enable display, then it’s view logic. Sure there’s page-flow which is defined by the customer, but it’s still the way the interface works, not the way the application processes data.

What about when the class does both, enables a view and implements business logic? The answer to that is pretty simple … your class is doing too much.

Persistence logic should pretty simple. There should be a way to find, create, update, and delete. Anything more than that is business logic.

I have a fourth class, that is utilities. All code that does something that has nothing to do with the application like xml parsing or string utilities(yes I know there are a ton of them them available to download, but this is an example) goes in the utilities.

Everything else is business logic. In my mind, if you correctly define the other three, business logic is like the junk drawer because it’s such a broad category.

- Comment @ WTF: Link.

Understanding the Problem Domain

As programmers we try to scrape by learning the least we have to about the problem domain, and instead lean heavily on people qualified to properly understand it.

Unfortunately, this means we cannot look ahead and we make some pretty stupid design decisions. A lot of the needless complexity and “over engineering” comes from a poor grasp of the actual problem. Meanwhile, we understand the technical issues very well, and so we quite properly manage to slot them into time-tested patterns.

- Comment @ WTF: Link.