Last night while re-reading a few chapters of Domain-Driven Design by Eric Evans, I came across the idea of high cohesion as it relates to layering applications. This relates to the GRASP High Cohesion Pattern I talked about with objects, so I thought I would talk about high cohesion as it relates to layering applications...
In terms of object-oriented design, cohesion is a measure of how strongly related and focused the responsibilities of an object are. An object with highly related responsibilites that does a little amount of work is considered highly cohesive.
When developing applications, you can also break the application up into layers, with each layer being highly cohesive (dealing with a separate concern). Using the very broad stroke of my pen, you might break up your application into the following layers:
- User Interface (Presentation Layer) : Displays the information to the user and responds to user commands (e.g. Web Page, Winform, etc.)
- Application Layer: Defines the services provided by the application and directs the user commands to the domain layer that actually does the work. This layer is kept thin and does not contain any business rules. It only delegates work. This sounds like a bunch of controllers as mentioned in Applying UML and Patterns. See GRASP Controller Pattern.
- Domain Layer: All the business rules and business objects within the problem domain.
- Infrastructure and Technical Services Layer: Object persistence and other such technical services needed by the above layers.
A paragraph from Domain-Driven Design by Eric Evans (Amazon) describes the ideas of layers very nicely:
“Partition a complex program into layers. Develop a design within each layer that is cohesive and that depends only on the layers below. Follow standard architectural patterns to provide loose coupling to the layers above. Concentrate all the code related to the domain model in one layer and isolate it from the user interface, application, and infrastructure code. The domain objects, free of the responsibility of displaying themselves, storing themselves, managing application tasks, and so forth, can be focused on expressing the domain model. This allows a model to evolve to be rich enough and clear enough to capture essential business knowledge and put it to work.” - Domain-Driven Design by Eric Evans p70-71
So cohesion not only relates to objects, but also to the layers of an application as well.
A Little Warning About Layers and a Model-Driven Design....
This sounds great on paper, but even as Eric mentions in his book, unless you are skilled at object modeling and assigning responsibilities to objects, a domain-driven design separated into highly cohesive layers can be a daunting task for even the simplest projects. I can vouch for that from my own experience.
Here again is a paragraph from Domain-Driven Design, which I highly recommend for your bookshelf:
“If an unsophisticated team with a simple project decides to try a model-driven design with layered architecture, it will face a difficult learning curve. ... The overhead of managing infrastructure and layers makes very simple tasks take longer. Simple projects come with short time lines and modest expectations.” - Domain-Driven Design by Eric Evans, p76
I've often thought that a good developer is one who knows how to apply design patterns and design guidelines, and a great developer is one who knows when to apply design patterns and design guidelines. Something easy to forget is that “simple” applications may often take longer to develop and be more difficult to maintain by less skilled developers if you create all these layers and follow architecture design rules to a “T”. This is why the ASP.NET Starter Kits are not even close to the practices preached in Microsoft Patterns and Practices.