If we have determined that our current architecture is too tightly coupled, we can safely decouple parts of functionality from our existing architecture. It involved placing existing functionality behind an API where it remains unchanged and implementing new functionality using our desired architecture. When we implement strangler applications, we seek to access all services through versioned APIs. Versioned APIs enable us to modify the service without impacting the callers, which makes the system more loosely coupled. Any arguments change causes creation of a new API version.
We are not achieving our rearchitecting goals if we allow our new strangler application to get tightly coupled into other services, for example connecting directly to another service's database.
If the service we call does not have clearly defined APIs, we should build them or hide the complexity.
By repeatedly decoupling functionality from out existing tightly coupled system, developers can become more productive and the legacy application will eventually shrink.
We create an abstraction layer between the areas we are changing. This enables evolutionary design of the application while allowing everybody to work off trunk and practice continuous integration.
Up front analysis helps us identify the smallest piece of work that will achieve a business outcome using the new architecture.
The architecture that our services operate within dictates how we test and deploy our code.
Architecture is one of the top predictors of the productivity of the engineers that with within and of how changes can be quickly and safely made
We must be able to safely migrate from one architecture to another.