Let me toss in an off-the-wall example. Yesterday, I was at a restaurant when the credit-card machine and apparently most of the other computers briefly went down. They handled the crisis with aplomb. Thus, for a very brief interval, the ORDERS table in some database somewhere was not being updated ... yet orders were still being processed. In other words, “I still got my food and drink.”

For a brief amount of time, the computer representation of an order, or a juicy steak, or an excellent martini, simply did not exist. The staff smoothly switched to using an entirely paper-based representation of that workflow, and they had no need at all to be concerned with digitized representations of my martini. Nothing “suddenly disappeared off my plate” when the computers crashed, nor was I stuck waiting indefinitely for something to eat. When the computerized representation of a business-object known as an “order” ceased to exist, the staff employed an alternate, paper-based representation ... and no matter what representation had been used to reflect it, I was still able to place “an order.”

Some restaurants allow me to “place an order” with a fax-machine. There is no “display logic” in that case. Others allow me to place an order with my iPhone:   different display-logic. But the business rules established by the management of that restaurant apply generally to “orders”... no matter how they are placed, represented, or tracked.

Many people confuse a computer database with the Things that its multitudionous records represent, or model. They construct software that accurately reflects what the computer is doing, but not what the business is doing. As those two paths inevitably diverge, the software becomes fragile and brittle and is well on its way to the bit-bucket.

An “order,” or a steak or a martini, exists and is processed in a certain way, according to certain rules, in the real world, whether or not the computer is in any way involved with the process. Those rules will inevitably change from time to time. As the real-world changes (or, as the nature of the computer/display technology changes, e.g. “everybody gets a Personal Holo-Deck Device™ and starts to place orders with it”), we must be able to constrain the scope of those changes. Changes must not ripple uncontrollably throughout the source-code.

This is the familiar notion of “separation of concerns.” The display-layer is concerned with interpreting the bytes received from the client's display-device and for preparing an appropriate stream of bytes to send to it. Other layers of concern check to see if those inputs meet various syntactic and contextual requirements. Other layers of concern deal with interaction with back-end systems or the outside world. Still others deal with issues of business logic ... these being defined as “issues that are just as relevant when you're handling orders on-paper as they are when you're using the computer.” In my opinion, there are many layers above-and-beyond the familiar three: M, V, and C. Many of these layers are asynchronously or otherwise loosely-coupled with one another.