9
I noticed that we don’t have a question about this topic.
Separation of Concerns (Soc), also known as:
I’d like to know:
Optionally, a good material to read about (Dijkstra, etc.)
4
To understand what the Separation of Responsibilities means, let’s see what the first principle of S.O.L.I.D is.: Sigle Responsability Principle (SRP), or Single Liability Principle.
This principle says that, in a very simple way, a class or module has a single responsibility, or we can say that, of what the software does, such module or class is responsible for only "part".
For example, in a product query system, a class that only query the product data in the database, is adhered to the SRP.
It is important to understand that, this principle aims to make it easier to maintain and understand the system, since a code has a single responsibility, it is easier to know where it needs to be changed to do a certain maintenance or new functionality.
The Separation of Responsibilities is a principle/standard software architecture that has the same principle as SRP, but with a slightly more macro view, not at class level, but package level, Assembly, etc, which aims to separate the application into "parts" who are responsible for different responsibilities.
For example, if the above example class (let’s call it Repositorioproduct to facilitate), and this class is in a package that contains another class (let’s call it Repositorioclient), that is responsible for consulting the customer’s data, it seems reasonable to say that they, within their unit functions, has similar functions, which we could say are to obtain information from the database.
Now imagine that we have another class that format the product data to be displayed to the user, and we’ll call it Formatproduct. From the point of view of SRP, this class is adherent, it only does one thing, but if it is in the same package, Assembly, etc, that class Repositorioproduct, it is not adhering to the Segregation of Responsibilities, because one class has a responsibility at the level of data repository, and the other at the level of presentation to the user, so they must be separate.
This separation can be done logically or physically, and is usually implemented by creating layers (layers) in the code.
We have the classic Presentation/Business/Repository model, the well-known 3 layers, where each package, project, Assembly has a responsibility.
Within these components we can have infinite classes with subjects in common, making responsibility well defined.
This separation can also be done in a logical way, grouping the components within the same package but in a way that is easy to identify.
This happens with projects that use the MVC standard (Model, View, Controller), that in many projects, despite the separation of responsibilities, may have the components in the same package, but logically separated, in folders, namespaces, etc..
Below is an example of the logical separation of project responsibilities using the MVC standard
This has several benefits, we can think for example:
Ease of understanding of the components: if the separation is well implemented and we need to change the way something is displayed to the user, we can change only some class of the presentation layer;
Help estimate maintenance or new features: it’s easier to look at only one part of the code and estimate effort if we know well where it will be necessary to change;
Decoupling: If each layer has its own separate responsibility, it is easier to decouple each layer. Here are two interesting situations: we can change and publish only one code package instead of the whole code if the change is in a layer. It is still possible to replace an entire layer without affecting the rest of the code depending on how it is implemented. It could for example replace the database without having to change the other layers, or even the presentation layer, by changing from a desktop application to a web application for example.
2
Well, any Pattern originates from a recurring problem and a standard approach to its solution has been found. So I believe that even though you don’t know it, you already use some level of Soc without even knowing it. And when I say level understood, "applied granularity level", where the lowest level of granularity could generate multiple Code Smells and the highest level could be considered an overengineering. Therefore it is up to those involved in the project to define what is the best level to apply and monitor whether it is being followed. Recalling also that Soc is not only for Backend development but in the design of architecture as a whole, and goes from the definition of architecture to the definition of an entity. Let’s take an example at a lower possible level of granularity in a web application, which a long time ago was common practice in ASP, PHP, Java and subsequent improvements were thoughtful towards Soc.
Level 0 - No Soc - All together and mixed
HTML/Javascript/CSS/Backend Code on the same html/jsp/php/Asp page; Variables, business rules, bank access (Connection opening, bank queries). Positive: You knew that everything that referred to a screen for example, would be in the screen file Negative: No entities, classes of services, nothing, having to find defined business rules within a, lawless land, hell on earth.
Level 1 - MVC - Division into logical layers
View - Everything that represented the presentation of data, such as a page or a report, is still via back end code between HTML, CSS and Javascript Controller - Page flow definition, still see bank code in these classes, utility classes for connection Model - Database Entities, Dtos, Viewmodels, Vos, etc - Classes to Crunch and Traffic Data Positive: A little more organized Negative: This model still saw the use of business rule in all layers
Level 2 - BO/DAO
In this model, business classes (Business Object - BO) were introduced. Large Bank Access Classes (Data Acess Object - DAO) Database connection utility classes, Log, Data parse, etc.. Positive: The business rules were separated from the MVC, being used only when necessary, better reuse of code. Negative: Classes did not have a "single responsibility", i.e., any part of the system could be responsible for the rise of a class.
Level 3 - Services/Repositories
Better separation of business rules and data access. Each service/Repository represents the business rules and definition of data access of a screen, Feature or entity. From here you already see much the use of DI (Denpendency Injection). S.O.L.I.D. in high, cohesive classes, cohesive, cohesive methods. Positive: A better definition of Single Responsibility, simplified maintenance, each class grows depending only on what it was created. Negative: Increase in the number of classes, more work pro Gcs if necessary the use of DI (Denpendency Injection) to control the live Class Ycle.
Level 4 - Separation into physical layers
Physical separation between layers with "unique" responsibility (or at least they should be unique). Each layer would be a project, Assembly, dll, jar, etc. linked together. Ex: Web, Test, Bussiness, DAL (Data Access Layer) Ex2: Web, Services, Repositories, Domain, Core Positive: No longer a monolith. Small projects that can be updated idependente depending on the situation, simplified maintenance. Negative: Care should be taken to maintain the sanitation of projects, keep them cohesive, versioning control.
Level 5 - API, Web Services - Front End completely separated from the Back End
In this mode, you could have a web application, a mobile, using the same API. Use of SOAP, REST, Messageria, and other distributed system resources. Here we already talk about Isolate of Concern, isolated applications integrated with each other, for designing a product. It should be respect interface contracts for integration to remain cohesive. Positive: Each one in its square, nobody touches what should not touch, less code to maintain, it is easier to find that part of the system needs more attention. Negative: Basically we are dealing with a distributed application, ie to form a single system, if it takes several applications, distinct, with different versions, distinct deploys, maybe even teams, if it is not done right, can generate headache.
Level 6 - Microservices
Further segregation of a system, even involving bank segregation. Each Microservice can be independent or not. Division of a single system, taking into account the load (has many accesses, is heavier, traffic more data, critical) or domain (referring to a module). Each Microservices has its own responsibility, its own reason for existence, and grows according to its own needs. Cloud, Devops; Positive: Each Microservice could be maintained by a small team, maintaining a contract in its interfaces Microservice is easy to maintain, easier to test, can be built in language/independent bank, making it easier to optimize. Negative: While Microservice is easy to maintain, the Microservices application is extremely difficult to maintain without Devops, making it necessary to maintain resources in a Cloud orchestrator.
Level 7 - Servless
Instead of segregating by domain, why not segregate by function? Each servless service correlates the lowest executable part of an application. This is the least responsibility maintained to date, use with caution, in prone situations. A solution can be a monolith and have a servless feature. If used correctly, it can have a huge economy in certain application activities. There are other poréms of this architecture, several discussions involving her, but I will leave aside to keep the brevity. Positive: Easy to remember code, smaller scope. Negative: May cause exaggerated cost if done incorrectly, difficult deployment, slowness to climb if the application is cold, difficulty.
At any one of these levels it is possible to do something functional and maintainable, just as something untenable can be done. And overall it will depend on how your application is.
Make an application in 10, 20 layers? The system will never grow, why split in layers? A single Library of your system, is separated into 10 service classes? Need to use Microservices? And Servless? You are prepared to manage this?
Browser other questions tagged software-engineering software-project programming-principles
You are not signed in. Login or sign up in order to post.
I’ll see if I can do something nice. This is one of the things that we know what it is but it is not easy to define :) Anyway studying what it is does not help much to do right except by the fact that there is not completely blind in the subject, as all we have to do with systems.
– Maniero
It also fits [tag:design-Patterns]?
– Jefferson Quesado
Even you, @Jeffersonquesado. It’s not a Pattern design, it’s a principle.
– Piovezan
@Piovezan by ignorance I asked, honestly I have difficulties in distinguishing the "principles"
– Jefferson Quesado
@Jeffersonquesado It is a design principle. Do not ask what is a, here I ask the questions :D
– Piovezan