生鲜电商中微服务体系的分层设计和领域划分.docxVIP

生鲜电商中微服务体系的分层设计和领域划分 2021-12-13 本文阐述了一种将分层设计和DDD领域设计思想应用于微服务体系架构的方案实践，也是个人的最佳实践。 对于大部分互联网公司来说，我们主意将其Web服务架构分为五层：基础设备层、领域服务层、应用服务层、网关层和用户界面层（表示层）。 领域服务层和应用服务层均可以接受微服务设计进行拆分，其中领域服务层将依据DDD领域设计进行领域划分，设计为一个个领域模块微服务，每个微服务高度内聚，仅关注本人的业务，领域服务间通过接口调用进行松耦合。 这种设计方案可以大大简化大系统，并且在后期的维护中优势会日渐凸显，然而把大系统分而治之拆成微服务同时也对架构师和开发人员提出了更高的要求。 第2部分引见了相关背景，接着第3部分探讨了分层设计以及每一层的功能，第4部分结合微服务和DDD对领域服务层进行服务模块划分和设计。第5部分则就分层设计和DDD领域设计中常见的问题进行了整理。 背景引见 想写这样一篇文章很久了，虽然学的是软件工程，但碍于本人力量有限，从08年写代码以来一直断断续续的思考，一直对项目模块设计和分层结构设计没有一个可以让本人觉得满足且无纠结点的答案，假设了某个设计，很快在实践中又会发觉其存在着一些问题。 直到工作了解到DDD领域驱动设计后，才有了相对清楚的方向。 实际上早在2004年，Eric Envas的《领域驱动设计：软件核心简单性应对之道》就已出版，到底软件开发自计算机普及以来已经存在很长一段时间了，晚期国外程序员对软件开发理论的争辩也格外兴盛，如今成熟后反而争辩的相对少了，基本上依葫芦画瓢即可。 DDD领域驱动设计对软件设计各个环节的人员都有较高的要求，用《领域驱动设计》一书的话来说它需要一个“领域驱动团队”，它要求从分析阶段，产品经理、项目经理、架构师以及开发工程师就使用统一的模型言语（Ubiquitous Language）来进行沟通，并且他们都懂一些代码、产品和建模相关的学问。 现实上这在国内很难实施，国内的产品经理约等于需求整理工，对其计算机基础的要求是少之又少，在我所从事的公司里，也曾发生过产品经理直接指点开发，以至于后面双方理解的同一个词有着不同含义的情况。 所以本文不打算去阐述DDD领域内部建模代码级别的实践，甚至本文并不认为贫血模型是不好的，本文次要探讨领域之间的划分和分层设计，这是设计美丽?系统的第一步。 另外提一句：其实合理设计的微服务体系中的服务本身就是功能单一边界清楚的小应用，届时贫血也好、DDD领域建模也好，其实都可以胜任。近年来，随着分布式的进展，传统中小型机集中式服务器已经不在流行，所以微服务体系也成为了各大互联网公司主流的选择。 直观的感受下微服务和DDD两者，好像一个是微系统，另一个则是大系统的设计方法，好像两者天生互斥，微服务化的小系统也用不着DDD，其实并不是，DDD是针对整个简单的软件处理方案的一种科学设计方法，微服务化也是把简单的大系统拆分为小系统，便利维护和管理，所以两者都有一个特点——为简单的大系统服务。 下面我们就来探讨下，如何把DDD的领域设计和其主意的分层设计应用到微服务体系架构中。需要说明的是本文次要是个人多年来的一点总结，未必适合全部场景，有更好通用性更为广泛的方案请不吝赐教。 分层设计 精确?????的说分层设计（Layered Architecture）跟DDD没有必定的联系，我最早接触分层设计是在携程网，当时内部使用的应当只是简约的业务层（Biz）和表示层，数据库访问之类的也是放在各自的业务包下的。 后来接触和学习了《领域驱动设计：软件核心简单性应对之道》，书的第4章“分别领域”中说到了四层分层设计，即：基础设备层、领域层、应用层和用户界面层（表示层）。 DDD产生的年月微服务还未流行，当时甚至基于扫瞄器的Web应用都比较少，更多的是PC软件和EJB等网络应用，所以作者更多的是想表达对简单系统的规律分层，并不在意每个领域是单独的系统还是一个软件系统内不同的模块。 所以为了跟其做区分，我们建议的四层为在其基础上引入“服务”两个字，即：基础设备层、领域服务层、应用服务层和用户界面层。这样做的意图是让开发人员马上可以了解到——每个领域模块即一个微服务（一个领域可以对应一个或者多个模块Module）。 摘要中提到我们主意的分层体系中还有一个层，即网关层，这又是什么鬼呢。 刚刚提到的DDD的时代背景，PC软件系统或者企业内部使用的网络应用系统是根本没有网关层（有也是网络网关设备）这一说的。 而现如今互联网公司产品的输出方式无外乎Web应用（网站、或者网络服务），并且为了更好的适配PC站和App，一般会接受前后端分别的应用设计方案，这时候会产生一个需求——内部网络应用系统如何把本人的服务输出到互联网上，