Decomposition of a system

Once I participated in a project that contained a lot of legacy code, which hindered the development process and was quite brittle, as there were no tests at that point. So I proposed to the customer that, in order to continue development of the system, we create an anti-corruption layer — i.e., a clear boundary between the legacy part of the system and the new code, which would be of higher quality and covered with tests.

In order to reduce complexity, we decided together against a microservices architecture. However, I pushed the idea of creating a kind of modular architecture where, if needed, we could later separate services further. So the result was a modular monolith architecture.

As I continued to participate in that project, we slowly migrated the old legacy code to the modular approach: we first covered the old chunks with tests, created a kind of facade for the future module, and then replaced that old chunk with code that would satisfy all the tests related to it.

The rule for decomposition was the preservation of business domain logic. So all the necessary rules lived together, and code related to a single consumer was kept in one place.

The process was not very fast, but as a result, I significantly improved the velocity of new feature delivery.