Doug Ross @ Journal

Software Layering Principles

Martin 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