Software Architecture for Engineering Managers: Separation of Concerns
When building software applications, clarity of vision is essential. Principles are valuable in clarifying our vision in life because they guide our choices and behavior. In software development, architectural principles have the same effect on the choices and behavior we adopt when we build systems and applications. There are several fundamental software architecture principles to be aware of. This article focuses on the Separation of Concerns (SoC) principle, including what it is and why it matters.
Imagine visiting a home where cleaning chemicals were found next to produce in the refrigerator, the washing machine was located in the basement, and the dryer was up in the attic, and entering the house by the front door, back door, or garage door required not one, but three distinct keys. This scenario seems silly and irrational. Why? Because it's dangerous to store food and cleaning chemicals in the same location. Laundry would become more frustrating if switching loads required walking up and down multiple flights of steps. And requiring a homeowner to carry three different keys to enter their home is redundant. Yet, when the Separation of Concerns principle is ignored, our software can look like this hypothetical home.
What is the Separation of Concerns principle? It is the cause-and-effect experiential observation that divides systems or applications into distinct and manageable components with logical or physical boundaries. Each component fulfills a meaningful and intuitive role, which makes it easier to maintain, modify, and reuse individual components without negatively affecting the entire system.
The Model-View-Controller software design pattern is one example of the Separation of Concerns principle. It emphasizes separating data handling, display, and logic in an application.
Microservice architectures are another example of this principle. This approach establishes independent services comprising related functions responsible for doing one thing well. As a result, each service knows little to nothing about the others. Yet, communication between services is achieved using a defined communication strategy, such as APIs, a publisher-subscriber event-based approach, or remote-procedure calls.
A third example of the Separation of Concerns principle is the Open Systems Interconnection (OSI) model describing the seven layers computer systems use to communicate over a network. The OSI model creates boundaries between transmitting raw bit streams over a physical medium at the Physical Layer from deciding which paths the data will take at the Network Layer and ensuring that data is in a usable format at the Presentation Layer, with additional layers responsible for other distinct jobs.
When designing software with the Separation of Concerns principle in mind, several questions can ensure that best practices are followed.
As we plan, design, and build software systems and applications with the Separation of Concerns principle in mind, we experience several benefits, including increased modularity, improved maintainability, better code organization, increased reusability, improved testing, reduced coupling, and better scalability.
Overall, following the Separation of Concerns principle can lead to a more organized, maintainable, and scalable software system, reducing development costs and improving user satisfaction.