What is separation of concerns in software architecture
Separation of concerns is a software architecture design pattern/principle for separating an application into distinct sections, so each section addresses a separate concern. At its essence, Separation of concerns is about order. The overall goal of separation of concerns is to establish a well-organized system where each part fulfills a meaningful and intuitive role while maximizing its ability to adapt to change.
How is separation of concerns achieved
Separation of concerns in software architecture is achieved by the establishment of boundaries. A boundary is any logical or physical constraint which delineates a given set of responsibilities. Some examples of boundaries would include the use of methods, objects, components, and services to define core behavior within an application; projects, solutions, and folder hierarchies for source organization; application layers and tiers for processing organization.
Separation of concerns - advantages
Separation of Concerns implemented in software architecture would have several advantages:
- Lack of duplication and singularity of purpose of the individual components render the overall system easier to maintain.
- The system becomes more stable as a byproduct of the increased maintainability.
- The strategies required to ensure that each component only concerns itself with a single set of cohesive responsibilities often result in natural extensibility points.
- The decoupling which results from requiring components to focus on a single purpose leads to components which are more easily reused in other systems, or different contexts within the same system.
- The increase in maintainability and extensibility can have a major impact on the marketability and adoption rate of the system.
There are several flavors of Separation of Concerns. Horizontal Separation, Vertical Separation, Data Separation and Aspect Separation. In this article, we will restrict ourselves to Horizontal and Aspect separation of concern.
Horizontal separation of concerns
Horizontal Separation of Concerns refers to the process of dividing an application into logical layers of functionality - UI, Business Logic and Database.
Having talked about the advantages of separation of concerns, the challenge remains in how we implement and ensure compliance. This is especially difficult for complex applications, especially applications that have been inherited and that have been under maintenance/development for several years.
A tool like CAST Imaging can help you evaluate the level of separation of concerns. By abstracting the complexity of the application and software architecture, the tool enables you to focus and strategize to achieve the desired level of separation to enhance maintainability.
Aspect separation of concerns
Aspect Separation of Concerns, better known as Aspect-Oriented Programming, refers to the process of segregating an application’s cross-cutting concerns from its core concerns. Cross-cutting concerns, or aspects, are concerns which are interspersed across multiple boundaries within an application.
The CAST imaging tool can help us visualize the cross-cutting concerns such as logging.
In cases of development of new applications, enforcing design patterns and software architecture compliance is a challenging task. The CAST imaging tool can be run after every release to ensure compliance to the design pattern.
You can also get a first-hand experience and complimentary access to CAST Imaging by clicking here.
[Additional suggested reading : How to use strangler pattern for microservices modernization]
Erik Oltmans, an Associate Partner from EY, Netherlands, spoke at the Software Intelligence Forum on how the consulting behemoth uses Software Intelligence in its Transaction Advisory services.
Erik describes the changing landscape of M & A. Besides the financial and commercial aspects, PE firms now equally value technical assessments, especially for targets with significant software assets. He goes on to detail how CAST Highlight makes these assessments possible with limited access to the targetâ€™s systems, customized quality metrics, and liability implications of open source components - all three that are critical for an M&A due diligence.