Explaining microservices patterns

Many years ago, I had the opportunity to work as a system architect and developer on an administrative–financial system. This involved the use of modules, such as accounts receivable and accounts payable, inventory control, purchasing, payroll, accounting, and so on.

 

 

The whole system was composed of several modules, and the delivery of the system was constructed in a modular way too. At the end of the application development, we had a large, integrated system with many dependencies between the modules. It was obvious that the system should be integrated, and we knew that very well. However, this integration was made with many dependencies and a strong coupling between modules. Sometime later, we also discovered that the dependencies and strong coupling were unnecessary.

We faced a lot of problems in maintaining the application (such as difficulty in implementing new frameworks and excessive bureaucracy), including the fact that whenever there was a need...