微服务拆分的非业务因素，以及"量力而行"原则

理论上，一个限界上下文对应的领域模型就可以设计成一个微服务，但领域建模只从业务视角出发，没有考虑一批同样会决定拆分结果的非业务因素：需求变更频率不同的功能应该拆开，避免变动频繁的业务发版连累相对稳定的业务；性能压力大的功能应该拆开，避免它占用的资源拖累其他业务、造成资源浪费；应尽量避免因拆分而调整组织架构，微服务项目团队规模宜控制在10～12人，把沟通边界收在小团队内部；有特殊安全要求的业务应该独立出来，避免不同安全等级的数据和逻辑混在一起带来泄密风险；存在技术异构（如同一业务领域内一部分用Java、一部分用.NET或大数据技术栈）的功能，可以按技术栈边界拆分。这些因素共同服从一条更高层的克制原则：微服务拆分应该是”自己能掌控的微服务”，而不是教条主义式的过度拆分——微服务拆得越细，集成、运维、监控和问题定位的成本就越高，如果项目团队还不具备云计算、DevOps、自动化监控这些支撑能力，硬拆出太多微服务只会拆出一堆自己掌控不了的分布式复杂度。只要在设计之初用DDD战略设计方法把逻辑边界划清楚、分层做到位，即使暂时保持单体形态也未尝不可——等技术能力和运维能力真正跟上后，因为边界本就清晰，随时可以轻松重组出新的微服务，不需要花太多时间和精力。