Put code that changes frequently together in the same module (or service), and separate code that changes at different frequencies into different modules (or services)

Change control from a traditional perspective (may imply reducing changes): * Purpose: Minimize changes to keep the system stable. * Process: Strict change approval process, extensive documentation, long testing cycle, and limited release frequency. * Result: The system is relatively stable, but the release cycle is long, the response to market changes is slow, and the speed of innovation is limited.

Change control as understood by microservice practitioners (not for the purpose of reducing changes): * Purpose: Better manage and control frequent changes to improve delivery speed and quality. * Process: Emphasize automated testing and continuous integration * Result: Able to respond to changes quickly, iterate new features quickly, fix bugs in a timely manner, and reduce the risks of changes through automation.

They prefer to build and improve software in an iterative, incremental manner rather than having a perfect plan from the beginning.

Visibility and monitorability into communications and dependencies between components