Wednesday, January 12, 2005

Software Layering Principles



Click here for AmazonMartin Fowler recently solicited input from participants in an enterprise software workshop. The topic? Preferred software layering principles (hat tip: John Lim). Participants were free to suggest principles and vote on any with which they agreed or disagreed.

They didn't appear in any particular order in Martin's blog, but I thought I'd reorder them from agree-to-disagree ratio (first number-to-last number) so that we can easily see consensus.

I was especially interested to see how many folks preferred to throw exceptions between layers (highlighted). I couldn't agree more.


* Business layer only uses abstractions of technological services. 14/0
* Layers should be testable individual. 12/0
* Separation of concerns. 11/0
* Layers are a logical artifact that does not imply distribution between layers. 11/0
* Low coupling between layers, high cohesion within them. 10/0
* Inbound external interface modules (eg web service handlers) should not contain business logic. 10/0
* User interface modules should contain no business logic. 10/0
* Business logic layers contain no user interface and don't refer to user interface modules. 8/0
* No circular references between layers. 8/0
* Layers may share infrastructural aspects (eg security) 7/0

* Layers should be shy about their internals. 8/0
* Lower layers should not depend on upper layers. 6/0
* Adaptability: be able to change. 2/0
* Layers should be substitutable. 2/0
* Layers should be independently maintainable and versioned. 2/0
* A layer should be wary of exposing lower layers to upper layers. 1/0
* Layers can have multiple adjacent upper layers. 2/1
* Every layer should have a secret. 3/2
* Layers should be agnostic of consumers (a layer shouldn't know who's on top of it.) 4/4
* Prefer layers to interact only with adjacent layers. 4/4

* Always wrap domain logic with a service layer. 4/5
* Layers should only interact with adjacent layers. 2/3
* The domain layer should not talk to external systems - the service layer should do that. 2/3
* Changing a lower level layer interface should not change upper layer interfaces. 2/5
* There are at least three main layer types: presentation, domain, and data source. 3/9
* Separate development teams by layer. 1/22
* Layers should have separate deployment units (eg separate jars or assemblies for each layer). 0/7
* Rethrow exceptions at layer boundaries. 0/15
* Distribute at layer boundaries 0/18


Martin Fowler: Layering Principles

No comments:

Post a Comment