Bounded isolated components

We have defined the architectural vision for our cloud-native systems and enumerated the patterns used to build these systems. The next step is to decompose a system into bounded isolated components. However, “What is the right size?” is a fundamental question that everyone asks. Ultimately, every team has to answer this question for itself. You have to ask yourself how confident you are that you can continuously deploy and scale each component. If you cannot be certain of the implications of a given change to a component then the component is potentially too large. If you have to make compromises on the scalability and tuning of a specific component then it likely needs to be split apart. If the backlog of changes to a component starts to clog then this is an indication that it may need to be refactored into multiple components. The potential scenarios may be limitless. In this section, we discuss common strategies for decomposing cloud-native systems into bounded isolated components across both functional and technical dimensions. These are not independent strategies. You will use all these strategies in different combinations for different components. Embrace disposable architecture in an effort to reach the optimal decomposition by executing controlled lean experiments, as we will discuss in Chapter 6, Deployment.