add new chapter about SRP and shallow modules

README.md

@@ -152,7 +152,7 @@ A modern implementation of this interface has **hundreds of thousands of lines o
 If you think we are rooting for bloated God objects with too many responsibilities, you got it wrong.  
 
 ## Shallow modules and SRP
-All too often, engineers end up creating lots of shallow modules, following some vague "a module should be responsible for one, and only one, thing" principle. What is this fuzzy one thing? Instantiating an object is one thing, right? How about saving a user? We introduce things like `MetricsProviderFactoryFactory` and `UserSaver` classes, and all they do is one tiny thing. The names and interfaces of such classes tend to be more mentally taxing than their entire implementations, what kind of abstraction is that? That's all very wrong.  
+All too often, engineers end up creating lots of shallow modules, following some vague "a module should be responsible for one, and only one, thing" principle. What is this fuzzy one thing? Instantiating an object is one thing, right? How about saving a user? We introduce things like `MetricsProviderFactoryFactory` and `UserSaver` classes, and all they do is one tiny thing. The names and interfaces of such classes tend to be more mentally taxing than their entire implementations, what kind of abstraction is that? Something went wrong.  
 
 We make changes to our systems to satisfy our stackeholders and users. We are responsible to them.