Start with a boundary you can explain
In a small business application, inventory and purchasing may share several rules and records. Separate those concerns in the code before deciding they need separate deployments. A useful module has a clear responsibility and controlled interactions; it should not depend on reaching into every other module's internal data.
Ask what independence would buy
A separate service may help when one area has distinct release, scaling or ownership needs. It also adds network failures, deployment coordination and more places to investigate an incident. Compare those responsibilities with the team's current operating capability rather than choosing the pattern from its popularity.
Keep the decision revisable
Document the reason for the chosen boundaries and the signals that would justify changing them. Start with a representative workflow and test its dependencies. If the domain changes, an understandable modular structure can make the next decision easier. Architecture is a response to constraints that should remain visible.
Further reading from the original publisher: Microsoft: common application architectures ↗