In this chapter, we’re going to continue tracing these Intentions further up the Change Stream, starting with the Cause.
In the next few chapters, we are going to come to an Engineer's aid and teach him how to do overcome the stream's unsteadiness. Starting with this one, with something that might seem as a contradiction to Software Engineering and Changeability.
Applications are far more complicated than just being dependent on a third party package. They have a goal to serve customers, and fortunately the Product Manager is here to make sure of that. In this chapter, we’ll explore the problem Product Changes entails through the Change Stream.
In this chapter, we’re going to extend this principle mutual exclusivity of Causes and Directions of Change, to better fit the entirety of our application. One a step towards reusing it to resolve some of our bigger problems.
In this chapter, we’re going to use the principle of mutual exclusivity in order to resolve the problems we uncovered in Fragments of Change: Architecture of Products and Organizations. To minimize the need to continuously refactor our applications in order to withstand the unsteadiness of the Change Stream.
In this chapter, we’re going to try and define Directions within the Non-Technical cluster of Causes. We’d start doing so by understanding what differs Products from other entities, and then come up with another trick to reach mutual exclusivity between them.
When we applied mutual exclusivity of Non-Technical Causes on our design we also made a mess. We indeed created a Direction per Product, but the Product Modules were unable to Change together at all as we do sometimes need. They were too independent, and were unable to reach all the way over to the Non-Technical Modules. In this chapter we’re going to resolve this mess, starting with finally understanding what Products are.
We’ve put aside what the Source exactly is in order to keep our design aware that a Source exists and remain agnostic to it. Our application does not care whether it was the CEO who Caused an Engineer to Change or if it was the Engineer’s mother. In this chapter, we’re going to see what the Source is. More than that, we’re going to see what the Change Stream is.
For years I’ve been pondering what is the difference between the two. According to this series, one of the differences is the skill and action of modeling.
In this series, we will be learning how to model multiple applications and how they relate to the very same Change Stream. To do so, we’ll be learning about applicative splits. What to consider and what would be the outcomes of the actions of splitting one application into two. We’ll see how it affects costs, scaling, reliability, hiring and many other pure technical factors. And there is going to be one unique perspective we’ll be focusing on, on how splits affect our development workflow. To do so, we’re going to start this series by learning about Bottlenecks, Throughput, Back Pressure and Upstream Pressure. Starting with something we are all familiar with - deployments.