We all play the role of an Architect at one scale or another. We may not all have the title “Architect”, but in our daily work we make decisions about the architecture of the system. We may choose a language or a framework for new development. We decide which design patterns would be best, and which to avoid. Someone might consider any of these decisions to be “architectural”. Some decisions like which version of a library to use, are relatively small, while others such as monolith vs microservices can be huge. The obvious impact of decisions like these, show the importance that our architecture can hold to the company.
In my last post about the Clean Architecture (link) we talked about dependencies, and how we’d ideally like them all pointing “inwards”. That is, we want all the dependencies pointing away from code that might change, and towards code that is less likely to change. The reason we should be intentional about dependencies, is to limit how often we need to change our code. Changes will ripple along those dependencies. Additionally, we need to handle the behavior of dependencies when unit testing.