Choose microservices around independent change

Which change needs to happen independently?

Distributing an application across services does not create independent development by itself. If the same people must change and release every service together for each pricing rule, coordination remains. Network calls and additional operational work are added.

Microsoft describes independent deployment and data ownership as important characteristics. Our starting point is therefore a concrete change: which business area should be able to carry it without simultaneous changes elsewhere?

Example: quotes and orders stay together for now

This product and way of working are fictional. One team maintains quotes, orders and reports. Pricing rules change together in quotes and orders. Report formats have different change needs.

In this plan, the application initially remains a modular monolith: internal boundaries, shared delivery. Spring Modulith illustrates the distinction between a public module interface and its internals. Describing this separation is useful without choosing that particular tool.

Include operations in the decision

A separate reporting service would need to handle failures of its data source. Someone would need responsibility for deployment, monitoring and incident investigation. The team also needs rules for old and new interface versions working together during a transition. A separate process alone does not satisfy these conditions.

Record the reason for a later separation, such as a real need for independent delivery or a workload requiring different treatment. Revisit coupling, data access and operational effort. Modules released together can still have clear structure. Equally, a well-bounded service can be justified before the rest of the application is split. Service count is not a quality measure for this decision.

Sources

• Microsoft: Microservices architecture

• Spring Modulith: Fundamentals