As software architect and developers, we try to adhere to some core principles and standards. I was working with one of our new architects the other day and shared the following piece with him concerning the principle of Separation of Concerns. Quoting Wikipedia:
"In computer science, separation of concerns (SoC) is the process of breaking a computer program into distinct features that overlap in functionality as little as possible. A concern is any piece of interest or focus in a program. Typically, concerns are synonymous with features or behaviors. Progress towards SoC is traditionally achieved through modularity and encapsulation, with the help of information hiding."
For the purposes of the present discussion, the main area we want to focus is the separation of concerns across the tiers and layers of a software system. (Tiers being defined by physical, or potentially physical, boundaries, layers being defined by logical ones.) Take for example this stack of tiers and layers:
- Presentation Tier
- Pure presentation layer
- Business-oriented presentation layer
- Middle Tier
- Service layer
- Business logic layer
- Data access layer
- Database Tier
- Data access layer
- Data storage
Each of these layers and tiers has its own unique set of "concerns" (exactly what those are is more detail than we can get into here). When we design a given system, which may or may not look anything like the representation above, we decide on these layers and tiers with a particular separation of concerns in mind. It is the job of all programmers on the team to understand the design from this angle and to diligently maintain the separation of concerns. For example, if a programmer locates business logic in the presentation tier that clearly belongs in the middle tier, he or she is violating the separation of concerns and dramatically weakening the system.