January 1, 2014 Author:

In 2005 Martin Fowler attended a workshop on enterprise software development where he and the other workshop attendees came up with and voted on a set of application layering principles. After the workshop, he wrote an article on his website that listed each of the principles and the number of up votes and down votes each principle received.

When I read this article, I thought it provided an interesting insight into the positive and negative sentiment that developers felt toward each application layering principle. However, I really wanted to see the data presented in a way that made it easier to digest visually. So I took the liberty of creating a tabular visualization of Fowler’s data ranked in order of the positive sentiment towards each principle (i.e. up votes minus down votes). In addition, I color coded each principle to indicate positive, neutral, or negative sentiment.

Application Layering PrincipleUpDownScore
Business layer only uses abstractions of technological services.14014
Layers should be testable individual.12012
Separation of concerns.11011
Layers are a logical artifact that does not imply distribution between layers.11011
Low coupling between layers, high cohesion within them.10010
User interface modules should contain no business logic.10010
Inbound external interface modules (eg web service handlers) should not contain business logic.10010
Business logic layers contain no user interface and don’t refer to user interface modules.808
No circular references between layers.808
Layers should be shy about their internals.808
Layers may share infrastructural aspects (eg security)707
Lower layers should not depend on upper layers.606
Adaptability: be able to change.202
Layers should be substitutable.202
Layers should be independently maintainable and versioned.202
A layer should be wary of exposing lower layers to upper layers.101
Every layer should have a secret.321
Layers can have multiple adjacent upper layers.211
Layers should be agnostic of consumers (a layer shouldn’t know who’s on top of it.)440
Prefer layers to interact only with adjacent layers.440
Layers should only interact with adjacent layers.23-1
Always wrap domain logic with a service layer.45-1
The domain layer should not talk to external systems – the service layer should do that.23-1
Changing a lower level layer interface should not change upper layer interfaces.25-3
There are at least three main layer types: presentation, domain, and data source.39-6
Layers should have separate deployment units (eg separate jars or assemblies for each layer).07-7
Rethrow exceptions at layer boundaries.015-15
Distribute at layer boundaries.018-18
Separate development teams by layer.122-21

Source: http://martinfowler.com/bliki/LayeringPrinciples.html

Fowler cautions against reading too much into this list, for various reasons; however, I do find the list interesting because it seems to match, and reinforce, several intuitions I have about application layering principles. In addition, I think this way of presenting the data might be valuable to others as well, so I am providing it here, with credit to Fowler, as requested on his FAQ: http://martinfowler.com/faq.html

Share this Article