add new chapter about SRP and shallow modules

README.md

@@ -159,7 +159,9 @@ We make changes to our systems to satisfy our stackeholders and users. We are re
 > A module should be responsible to one, and only one, user or stackeholder.  
 > **Uncle Bob**
 
-This is what this Single Responsibility Principle is all about. But even now, this interpretation can do more harm than good. This rule can be understood in as many different ways as there are people. Looking back at how much cognitive load a decision induces is a more clearer way.   
+This is what this Single Responsibility Principle is all about. Simply put, if we introduce a bug in some one place, and then two different business people come to complain, we've violated the principle.  
+
+But even now, this interpretation can do more harm than good. This rule can be understood in as many different ways as there are people. Looking back at how much cognitive load a decision induces is a more clearer way.   
 
 ## Too many shallow microservices
 This shallow-deep module principle is scale-agnostic, and we can apply it to microservices architecture. Too many shallow microservices won't do any good - the industry is heading towards somewhat "macroservices", i.e., services that are not so shallow (=deep). One of the worst and hardest to fix phenomena is so-called distributed monolith, which is often the result of this overly granular shallow separation.