微服务架构应从业务还是技术视角构建？Spring MVC单体应用拆分困惑

Hey there! Let me break this down for you since I’ve walked this path a few times with my own team.

First off, let’s settle this: your plan to split your Spring MVC monolith into microservices based on business problem domains (like customer management) is not just good—it’s the industry-standard best practice for microservice architecture.

Why your approach is correct #

• This split aligns perfectly with Domain-Driven Design (DDD)’s "bounded context" principle: each microservice owns a self-contained business domain, with its own logic, data store, and external APIs. This hits the core microservice goals of high cohesion and low coupling dead-on.
• From a practical standpoint, it’s easier to align with team workflows (you can have a dedicated team own the customer management service) and minimizes cross-service dependencies. Scaling, iterating, and troubleshooting each service becomes way simpler down the line.

Unpacking the Wikipedia confusion #

Wikipedia’s definition of microservices tends to cover all possible split dimensions (like technical layers or user roles) to be comprehensive—but that doesn’t mean all those approaches are equally good.

The key thing to remember: Wikipedia’s entry is a reference of what microservices can be, not a guide to what they should be for most business applications.

Here’s clarity on the possible sticking points you might have seen:

• Splitting by technical layers (e.g., a separate "database service" or "cache service") is an anti-pattern for core business services—it creates tangled dependencies and defeats the purpose of microservices’ independence.
• When splitting by business modules, focus on sharp boundaries: your customer management service should only handle customer CRUD, lifecycle management, and related business rules—keep order or inventory logic strictly out of it.

Quick actionable tips for your team #

• Start small: pick the most independent, clearly bounded module (like customer management) as your first microservice. Validate your deployment, communication, and testing workflows here before moving to other modules.
• Preserve core logic first: don’t rush to rewrite the module from scratch. Port the existing business logic from the monolith to the microservice to keep functionality consistent, then optimize incrementally.
• Keep inter-service communication simple: use REST APIs initially instead of jumping into complex message queues. This lowers the barrier to getting your first service up and running.

内容的提问来源于stack exchange，提问作者SerchRac