The definition of SRP is to have each class (or module) to have a single reason to change. I don't see how that has anything to do with having each line be assigned a responsibility. If the line changes for the same reasons as it surrounding lines, then, they are part of the same component (to use the author's wording). My guess is that the principle is being taken literally from its name/acronym.

I've worked with probably 6 or 7 different "microservice" based systems at this point, essentially all of them are just distributed monoliths. I don't think I've met a single person at my company who actually know what the hell a "microservice" is.

I.e. within the domain are the (O) basic structures, relations and operations.

Then (T) practical supporting algorithms, tuned for performance in specific cases, serialize, visualize, or whatever.

Then (A) the code that uses O & A to implement the details of specific solutions or manage specific processes.

Wherever there is a well defined broad class of problems with shared structure, this approach has merit.

• Minimize AT -> A, T, O or X.

• Minimize A -> T, O or X.

• Minimize T -> O or X.

• Minimize O -> X.

Where Blood Type X is... Well its just code that doesn't need to exist. Now all possible code has a blood type. And highest productivity is to increase code in X.

As they say, less (OTA), is more! (X)