Architecture: principles for how to create multiple layers

Question

As we know, nearly every complex architecture contains multiple layers. In a management system, we can easily come up with data access layer, business logic layer, and presentation layer without too much thinking. I want to know if there is a clear principle for how to create multiple layers. PS: It's not limited to management system.

Answer 1

In software engineering, when designing systems, you have to adhere to certain design principles. If you do this right, the layers pretty much emerge on their own. Some of the principles are:

1. Open/Closed
2. Single Responsibility
3. Interface Segregation
4. The Release Reuse Equivalency
5. The Common Closure

There are others as well. You can read about them online or get a book by Robert Martin called "Agile Software Development, Principles, Patterns, and Practices"

Here's a link to the relavent chapter from the book.

Answer 2

I believe, the main layering principle is Separation of Concerns. It's not really bound to object-oriented design, but is software-engineering-wide (wikipedia article provides stack protocol as an example).

So typically we find functional areas (F1, F2, F3) and force ourselves to design components which do only one of them. We ask "What does X"? and if answer if "F1, F2, F3", we'll divide X to X1, X2, X3, which perform a single function each, but do that good.

Just an brief and exaggerated example

class SomeBusinessObject //Business logic, as we think
{
    bool HasAccess(User loggedInUser)
    {
           /* two lines below are clearly from DataAccess layer */
           string q = "select 1 from user_roles where id={0} and isadmin=1";
           bool hasAccess = DataAccess.Execure(q).Rows > 0;
           if(!hasAccess)
           {
                /* message pre-formatting is Presentation layer concern */
                var msg = string.Format("<b>You don't have access</b>";
                throw new SecurityException(msg);
           }
           return true;
    }
}

In the sample above our BL-class should know about data model and data access details; also it tries to pre-format messages for html-based UI. So probably we'll move formatting to a view; and extract sql query generation to DAL.

In general, there could be the following layers:

1. Presentation layer
   • UI rendering layer (typically views)
   • Presentation logic (presenters/controllers)
2. Service layer (can be omitted in relatively small systems)
3. Business logic. If we want to layer that, we could probably think about:
   • Business rules layer.
   • Validation layer.
   • Business logic itself.
   • Data transformation
   • Query services
4. Data access. Could be divided to two layers:
   • Abstract data access serving business layers
   • Exact implementations below, "DB" layer.

In general, there are two layer relationship rules:

1. Layer should "talk" only to underlying layers. (E.g. there should be no dependencies from, let's say BL to Presentation, of from DAL to BL).
2. Layer shouldn't "jump" over a layer. (Presentation shouldn't talk to DAL).

However, there are also cross-cutting features which are not really bound to any of layers. That's mostly true for logging, caching, etc. Some also could say about security, but I'm pretty sure it could be done in a layer-specific fashion.

Hope that helps.

Answer 3

The layered architectural style implies calling hierarchy. for something to be considered a separate layer its communications patterns with other layers should be restricted. a layer provides capabilities to layers above it and uses capabilities form layers above. In pure layered systems a layer can only see 1 step in the hierarchy (e.g. TCP/IP protocol architecture).

Layering advantages include increase in loose coupling and the evolvability of the different layers. The main disadvantage of layers is that you add latency and copy data over (passing from layer to layer) - so you have to consider the loose coupling vs. added latency when deciding on a new layer

In addition to that you should pay attention to the difference between layers and tiers - or layers that always reside on the same machine (layers) and layers whose boundary is across machines (tiers). When the layers are distributed you need to pay attention for more than just the latency (see fallacies of distributed computing) so you should have a very good reason to add a tier