知识卡片
限界上下文与微服务的对应关系:理论边界与不宜过度拆分的现实考量
内容
限界上下文和微服务边界之间存在层层嵌套的对应关系:一个领域可以拆分为多个子域(如保险领域拆成投保、支付、保单管理、理赔),子域还能进一步拆分为子子域(支付子域拆成收款、付款),拆分到一定程度后,某些子子域的领域边界就变成了限界上下文边界;一个子域内也可能包含多个限界上下文(如理赔子域包含报案、查勘、定损等多个限界上下文),也可能子域边界正好等于限界上下文边界(如投保子域)。限界上下文是微服务拆分时可以参考的业务领域边界——理论上,如果不考虑技术异构、团队沟通等外部因素,一个限界上下文(对应一个领域模型)是可以被设计为一个微服务的。但书中特别提醒:实际落地时微服务拆分还需要结合企业的真实情况和其他非业务因素综合考量,”不宜过度拆分微服务”,因为过度拆分会显著增加系统集成和运维成本。这提示:限界上下文给出的是业务边界该在哪里的理论指导,但”一个限界上下文是否真的要独立成一个物理部署的微服务”,还要额外权衡运维复杂度、团队规模等现实约束,理论边界和最终的物理拆分粒度不必强行画等号。
参考来源
- 位置:第6章《限界上下文:定义领域边界的利器》"6.4 限界上下文和微服务的关系"(源文件:_epub-src/OEBPS/Text/chapter3-2-4.xhtml)
- 结论依据:原文说明"限界上下文是微服务拆分过程中可以参考的业务领域边界。不过,这里还是要提示一下,虽然限界上下文理论上可以作为微服务的拆分边界,但实际落地时,微服务的拆分还是需要结合企业的实际情况,考虑其他非业务因素的限制条件……但需要记住一点:'不宜过度拆分微服务',这样会增加你的集成和运维成本",直接支撑本卡片结论。
- 原始内容:限界上下文是微服务拆分过程中可以参考的业务领域边界。不过……微服务的拆分还是需要结合企业的实际情况,考虑其他非业务因素的限制条件……但需要记住一点:"不宜过度拆分微服务",这样会增加你的集成和运维成本。