PEAA.1 – Layering

Layering is a common practice to separate and organise code units by their role/responsibilities in the system.

In a layered system, each layer:

  • Depends on the layers beneath it;
  • Is independent of the layers on top of it, having no knowledge of the layers using it.

In a layered architecture, the layers can be designed in a strict way, where a layer only knows the layer directly beneath it, or in a more flexible approach where a layer can access any layer beneath it, although the second case seems to work better in practice.

Sometimes the layers are arranged so that the domain layer completely hides the data source from the presentation. More often, however, the presentation accesses the data store directly. While this is less pure, it tends to work better in practice.

Fowler, 2002

The advantages are:

  • We only need to understand the layers beneath the one we are working on;
  • Each layer is replaceable by an equivalent implementation, with no impact on the other layers;
  • Layers are optimal candidates for standardisation;
  • A layer can be used by several different higher-level layers.

The disadvantages are:

  • Layers can not encapsulate everything ( a field that is added to the DB, most likely also needs to be added to the UI);
  • Extra layers can harm performance.

The three most used layers:

  • Presentation: The user interface, be it a web page, a CLI or a desktop window;
  • Domain: The logic that is the reason the application exists;
  • Data source: The data persistence mechanism (DB), or communication with other applications.

Choosing where to run your layers

Running on a two-tier system (client/server) is good because everything is easy to upgrade and fix as the application lives in a limited amount of places, namely just the server. There are no issues related to deploying to many and different desktops;

In the other hand, running a one-tier system (ie. fully desktop):

  • Has better/immediate responsiveness;
  • Is able to operate without a network connection.

I’m very much in favour of the web presentation if you can, and the rich client if you must

Pg. 24

This post is part of a set of posts with my personal notes about all the chapters in the book “Patterns of Enterprise Application Architecture” by Martin Fowler. I will do this as I read through the book, and take notes on the concepts I personally find more relevant.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s