Single responsibility

The single responsibility principle says that a component should have one and only one responsibility; the entire responsibility should be encapsulated in that component; it should do that one thing and do it well; it should have high cohesion such that everything in the component belongs together; it should have only one reason to change. The trick is determining what that one responsibility should be. The bounded context, component patterns and data life cycle decomposition strategies help us whittle components down, but here I want to focus on only one reason to change part of the principle. Part of the goal of cloud-native systems is to enable teams to rapidly deliver innovation with confidence, in other words, to deliver change fast. At the other end of the spectrum, we have discussed how monolithic systems hinder innovation, because we have low confidence that any particular change won't have unintended consequences on the system. Cloud-native systems are always on, thus we need to perform zero downtime deployments. We need to have bounded isolated components, so that we avoid failures in the first place, but also so that we can recovery quickly when there is a problem with a component. We need to have cohesive components.

Your team will have to be its own judge about the cohesion of your components. What is your confidence level with a particular component? If your confidence level is low, then discuss why. One counter intuitive possibility is that your confidence may be low, because you have too many tests. So many tests that it is hard to reason about their correctness. This could be a sign that the component has too many responsibilities. Categorizing the tests and splitting apart the component may lead to a breakthrough in the team's understanding of the problem space. Alternatively, the code itself may have grown convoluted. The amount of code in a component is not necessarily a concern. If there is a large amount of code, but that code follows a very clear pattern that is repeated over and over again, such as a set of rules on a concept, and those rules are easy to reason about, then so be it. However, if the code is hard to review, no matter how much code it is, then that is an indication that the component may have taken on too much responsibility.