电商系统中微服务体系中的分层设计和领域划分.pdfVIP

电商系统中微服务体系中的分层设计和领域划分

说明：在Java⽣鲜电商平台中，微服务体系的分层设计与领域划分应该怎么样呢？

看标题感觉这个东西很理论，⽐起“⾼并发、多线程”、“分布式CAP、⼀致性、Paxos”、“⾼可⽤SLA”等具体的⼲货技术点，软件体

系知识显得很“湿”，似乎⼈⼈都有⾃⼰的认识，但⼜很少有⼈能说完整，有⼀点可以确定的是，如果你未来需要独⽴设计⼀个复杂的系统

中台，并使之未来能快速应对各种需求变化的话，科学合理的领域划分和边界界定需要我们“处⼥座级”的坚持下去，这对防⽌⼈⼒失控、

减少项⽬烂尾很有帮助。合理的界定了边界后，即便某个微服务很糟糕，也可以就输⼊输出以很少的⼈⼒投⼊进⾏重构，相反的就是牵⼀发

⽽动全⾝，加上业务需求频繁⽽来，很容易烂尾或是达不到如期的效果。

其实很多技术⼤神都是某⼀个技术点的好⼿，但可能在整体软件体系上思考并不多，每个⼈都有⾃⼰的设计⽅法，⼤部分容易想到的设计⽅

法处理⼀般的系统已经够了，后⾯发⽣问题慢慢打补丁就⾏了，当我们⾯对各种需求变化陷⼊开发困境的时候我们就该想想了，咱们系统的

体系设计上是否出了问题？本⽂不打算涉及领域建模和设计模式等代码级别的详述，⽽是探讨如何将⼀个复杂的⼤系统进⾏分层和拆分，这

是设计⼀个优美系统的第⼀步，相信对各BU同事们快速搭建系统中台也是很有参考意义的。⽂中的⼀些例⼦⼤家也可能遇到过，⼤家如果

在开发中遇到困境，可以多来圈⼦交流和发表问题，⼤家⼀起学习进步。⼤概知道内容背景的可以直接跳到第3部分。想了解⼀个⼤项⽬如

何进⾏科学⼈员安排的可以直接看5.4部分。如果你的组⾥还有⼈把数据库模型当接⼝契约⽤，可以建议他看下5.1部分。假如你在开发过程

中遇到⼀些别⼈的开发设计习惯，你觉得不是很好，但是⼜不知道如何说服他，都可以到评论区聊聊，⼤家⼀起讨论讨论。

1.摘要

本⽂阐述了⼀种将分层设计和DDD领域设计思想应⽤于微服务体系架构的⽅案实践，也是个⼈的最佳实践。对于⼤部分互联⽹公司来说，我

们主张将其Web服务架构分为五层：基础设施层、领域服务层、应⽤服务层、⽹关层和⽤户界⾯层（表⽰层）。领域服务层和应⽤服务层均

可以采⽤微服务设计进⾏拆分，其中领域服务层将按照DDD领域设计进⾏领域划分，设计为⼀个个领域模块微服务，每个微服务⾼度内聚，

仅关注⾃⼰的业务，领域服务间通过接⼝调⽤进⾏松耦合。这种设计⽅案可以⼤⼤简化⼤系统，并且在后期的维护中优势会⽇渐凸显，然⽽

把⼤系统分⽽治之拆成微服务同时也对架构师和开发⼈员提出了更⾼的要求。第2部分介绍了相关背景，接着第3部分探讨了分层设计以及

每⼀层的功能，第4部分结合微服务和DDD对领域服务层进⾏服务模块划分和设计。第5部分则就分层设计和DDD领域设计中常见的问题进

⾏了整理。

2.背景介绍

想写这样⼀篇⽂章很久了，虽然本科学的是软件⼯程，但碍于⾃⼰能⼒有限，从08年写代码以来⼀直断断续续的思考，始终对项⽬模块设

计和分层结构设计没有⼀个可以让⾃⼰觉得满意且⽆纠结点的答案，假设了某个设计，很快在实践中⼜会发现其存在着⼀些问题。直到

2014年毕业⼯作了解了DDD领域驱动设计后，才有了相对清晰的⽅向。实际上早在2004年，EricEnvas的《领域驱动设计：软件核⼼复

杂性应对之道》就已出版，毕竟软件开发⾃计算机普及以来已经存在很长⼀段时间了，早期国外程序员对软件开发理论的研究也⼗分兴盛，

如今成熟后反⽽研究的相对少了，基本上依葫芦画瓢即可。DDD领域驱动设计对软件设计各个环节的⼈员都有较⾼的要求,⽤《领域驱动设

计》⼀书的话来说它需要⼀个“领域驱动团队”[1]，它要求从分析阶段，产品经理、项⽬经理、架构师以及开发⼯程师就使⽤统⼀的模型

语⾔（UbiquitousLanguage）来进⾏沟通，并且他们都懂⼀些代码、产品和建模相关的知识，事实上这在国内很难实施，国内的产品经

理约等于需求整理⼯，对其计算机基础的要求是少之⼜少，在我所从事的公司⾥，也曾发⽣过产品经理直接指导开发，以⾄于后⾯双⽅理解

的同⼀个词有着不同含义的情况。所以本⽂不打算去阐述DDD领域内部建模代码级别的实践，甚⾄本⽂并不认为贫⾎模型是不好的，本⽂主

要探讨领域之间的划分和分层设计，正如引⾔说提到的，这是