For a system of most any reasonable size and complexity, there is an advantage to using a layered architecture.  The common assumption for business applications is a three-tier architecture: with presentation, business domain and persistence layers.  Keep in mind, though, that architecture is fractal.  As you delve into a particular layer, you'll probably find use for layers there, too.

== Derivation of three-tier architecture ==

=== Extract the presentation from the business domain ===

As everyone knows, it is generally considered a "best practice" to decouple the presentation or view of an application from it's implementation or business logic.  This fact drives the existence of the presentation layer, and results in a client-server architecture with a rather thin client.

With the presentation layer separated, we can concentrate on creating a robust business domain layer that is not dependent on the particular sequence a user takes through the user interface.  We are also, then, well-situated for modifying the presentation layer for our convenience, or even providing multiple front-ends for the same business domain system.

=== Provide adapters to external systems ===

It is also a "best practice" to isolate the system you are developing from the vagaries of external systems not under your control.  A standard way of accomplishing this is to define an abstract interface that includes the capabilities your system requires, and then create an adapter that implements that interface and communicates with the external system.  The database, or other persistence mechanism, is a typical candidate for this treatment.

Once we abstract our persistence needs, we've evolved to the standard three-tier model.  This gives us the flexibility to substitute other persistence mechanisms, or to accomodate changes in our persistence mechanism, without altering our business domain logic.  The changes should all be confined to the adapter.   If the interface also needs to change, it's an indication that our abstraction was not robust enough--either it failed to provide the abstract facilities we really needed, or it asked for facilities that could not be implemented in the adapter.

== Within the Presentation layer ==

In modern systems, a common pattern of choice for the Presentation Layer is the Model View Controller pattern.  (See Martin Fowler's [[http://martinfowler.com/eaaDev/uiArchs.html|GUI Architectures]] for an excellent description of this.)  In this, the View component displays information to the user, and the Controller component interprets and reacts to input from the user.  Both of these components depend on the Model component--the View displays the Model and the Controller makes changes in the Model.  (The Controller also determines which View is next displayed, controlling the navigation of the application, but that is outside the scope of the current discussion.)

The Model, then, is the Presentation layer's view of the Business Domain layer.  (See also, Martin Fowler's [[http://martinfowler.com/eaaDev/PresentationModel.html|Presentation Model]].)

== Future discussion ==

 * Domain representation at the layer boundaries
  * Differences in the interface needs of Presentation accessing Domain from Domain accessing Persistence (including InterfaceSegregationPrinciple)

== Table of Contents ==
<<TableOfContents>>