How to identify which seperation suits my development.

Be suspicious of 1 to 1 relationships across separations. Yes even that FooTest class that tests the Foo class. Separations are more useful when they mean something. Yes it makes naming things easy but there is more power when classes aren’t joined at the hip with a buddy.

That doesn’t mean every class must work with every other one. But if you’re going to separate, make it useful.

It is all too easy to invent far more separations than are needed. It is all to easy to get a combinational explosion across separations. Look for meaningful separations where attaching this with that feels natural not forced.

The reason this advice is needed is because programming is hard. And it is so tempting to construct a pattern to force yourself to follow. Just so you can blindly follow it without thinking. Don’t give in to that. It leads to hyphenated names and meaningless combinations.

They’re seperating based on languages

No. They separated based on purpose. Each concern separated into different files. Someone looked at some of these purposes and invented a domain specific language for them (xml, css, html). Those that didn’t get a general purpose language thrown at it (JavaScript).

The different purposes came first. The languages came later.

The different languages can make us think that the separation is required and ccs is the only way to style. It’s not. But it does help us stay organized.

A good example of this is Spring. Spring lets you do construction in xml. Now nothing is stopping you from constructing your object graph in main but if the code base picks up an xml/spring construction habit it makes the new code stand out and construction becomes easier to police.

That is until @autowire annotations show up and now it’s hard to call this Java anymore.

Anyway, language can be used to encourage separations. But it’s just an illusion. Any turning complete general purpose language can solve what a domain specific language can solve. It just doesn’t look as cool when doing it.

Separating on the base of language is not separation of concerns. It’s only the consequence of SoC: SoC is the root cause that made you chose two different languages instead of one.

Separation of Concerns is to keep separate, things that may evolve differently and for different reasons. This principle leads to a design where user interaction concerns are separated from database concerns, or print concerns are kept appart from business logic concerns. The different components (classes, modules, …) can then be maintained more easily.

The separation of concern is primarily about functionality and purpose. As said, there can be a correlation with language, and there can even be a correlation with developper or teams, when different developpers/teams have responsibility for different parts or are specialized in some matters. But these are always the consequence of SoC and not the concern itself.

Most design practices have one goal in mind – maintenance.

When a component is changed it may become buggy. To minimize bugs we want each change to affect less components (we assume that a in a well designed system, bugs in one component do not affect other components, which is not a given). For a change to affect less components, components should be split in a way, that each potential change would affect only one. Predicting future changes is in general impossible, but there are some heuristics that help. SoC is an example of such heuristic – it dictates, that a change of requirements usually involves only one business process or entity or technical aspect. The conclusion is then that components should be split along business entity seams.

Unfortunately it does not work particularly well, because business entities and technical aspects are ill defined and inexact. Therefore SoC is not a particularly good heuristic most of the time.

SoC is very good for:

• data access layer, because persistence is usually a well-defined concern
• domain model isolation – because it often clear where business ends and infrastructure starts
• etc

Somewhat less good for:

• Presentation (UI)
• Scheduling
• etc

Awful for:

• Domain splitting
• etc

As it basically breaks down to a bunch of isolated cases, it is never a safe bet to talk about SoC in abstract, talking about specific case like separation of DAL from your business logic is much more effective (clear).

Just predict the future.

Separation of Concerns, in SOLID is talking about classes. ie. a class should have a defined purpose and stick to it. Like, Auth, SavingToDatabase etc

However, you also have “Layers” of concern, Data, Presentation, Business Logic etc which you want to separate out. So you wouldn’t put “Display the login screen” or “Save the logged in user” in your Auth class, even though arguably it’s the same concern.

Many people suggest “Clean Architecture” : https://github.com/martinmurciego/good-books/blob/master/Clean%20Code_%20A%20Handbook%20of%20Agile%20Software%20Craftsmanship%20-%20Robert%20C.%20Martin.pdf