03 Change Driven Design

In this series we are going to give in to it and find a beneficial way to handle Change. Stopping Change is impossible and doing nothing about it is non-beneficial. It sounds like we are giving up to this Cause-Change cycle, which is a trait of our binary thinking minds. Instead, we’re going to focus on these Cause-Change cycles, and how they affect our applications. Through it, we will come up with methods to better design our applications, which will slow down some of the evolutionary processes.

In this chapter, we’re going to further explore the correlation between the Changes Stream and the application's design. As the Change Stream is supposedly beyond our control, we are only left with designing our applications to fit it better.

In this chapter, as another step into the Change Stream, we’re going to talk about Intentions and the people who carry them through.

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.