Matthew Renze

Visualizing Fowler's Layering Principles


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 Principle Up Down Score
Business layer only uses abstractions of technological services. 14 0 14
Layers should be testable individual. 12 0 12
Separation of concerns.  11 0 11
Layers are a logical artifact that does not imply distribution between layers. 11 0 11
Low coupling between layers, high cohesion within them. 10 0 10
User interface modules should contain no business logic. 10 0 10
Inbound external interface modules (eg web service handlers) should not contain business logic. 10 0 10
Business logic layers contain no user interface and don't refer to user interface modules. 8 0 8
No circular references between layers. 8 0 8
Layers should be shy about their internals. 8 0 8
Layers may share infrastructural aspects (eg security) 7 0 7
Lower layers should not depend on upper layers. 6 0 6
Adaptability: be able to change. 2 0 2
Layers should be substitutable. 2 0 2
Layers should be independently maintainable and versioned. 2 0 2
A layer should be wary of exposing lower layers to upper layers. 1 0 1
Every layer should have a secret. 3 2 1
Layers can have multiple adjacent upper layers. 2 1 1
Layers should be agnostic of consumers (a layer shouldn't know who's on top of it.)  4 4 0
Prefer layers to interact only with adjacent layers. 4 4 0
Layers should only interact with adjacent layers. 2 3 -1
Always wrap domain logic with a service layer. 4 5 -1
The domain layer should not talk to external systems - the service layer should do that. 2 3 -1
Changing a lower level layer interface should not change upper layer interfaces. 2 5 -3
There are at least three main layer types: presentation, domain, and data source. 3 9 -6
Layers should have separate deployment units (eg separate jars or assemblies for each layer). 0 7 -7
Rethrow exceptions at layer boundaries. 0 15 -15
Distribute at layer boundaries. 0 18 -18
Separate development teams by layer. 1 22 -21


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:

Share this article: Share on Facebook Share on Twitter Share on LinkedIn Share on Google+