微服务体系中的分层设计和领域划分！

• 网关层：负责提供对外的HTTP服务或者其他网络应用层协议（这里是指OSI七层协议中的应用层，别混淆了哦）服务。该层从非业务逻辑角度对暴露到外部的接口进行鉴权、计费、风控、资源调配等操作。有些简易的系统中，改成可以合并入应用服务层中作为一个AOP存在。

• 应用服务层：定义软件要完成的任务，并且指挥表达领域概念的对象来解决问题。这一层所负责的工作对业务来说意义重大，也是与其他系统的应用层进行交互的必要渠道。应用层要尽量简单，不包含业务规则或者知识，而只为下一层中的领域对象协调任务，分配工作，使他们互相协作。它没有反应业务情况的状态，但是却可以具有另外一种状态，为用户或者程序显示某个任务的进度。

• 领域服务层：负责表达业务概念，业务状态信息以及业务规则。尽管保存业务状态的技术细节是由基础设施层实现的，但是反应业务情况的状态是由本层控制并且使用的。领域层是业务软件的核心。

• 基础设施层：为上面各层提供通用的技术能力，为应用层传递消息，为领域层提供持久化机制，为用户界面层绘制屏幕组件（PS：这个在互联网应用中几乎用不到）等等。互联网Web应用系统中基础设施包含了数据持久化服务，中间件服务（数据库，Redis，Memcached，zookeeper，ELK等等）以及第三方服务等。

各层除了实现自己的功能外，还需要遵守以下原则：

1. 每一层设计保持内聚，并且只依赖于它的下方的层。

2. 下层向上层发起的通信只能通过中间件等间接方式进行。[2]

3. 上层和下层只能有松散耦合（各自为独立个体，通过简单引用关联）。在某些微服务框架比如Dubbo中，可以把api包提供给上层引用即可。这也符合依赖倒置原则。

这里重点说明应用服务层和领域服务层之间的关系。举一个我经常跟部门其他开发举的一个例子：有一家上市企业A公司，靠卖水果发家，其首席架构师科学合理的按照DDD搭建了一套基于微服务体系的卖水果应用，其架构图如下：

今年水果行情一般，而房地产十分火热，A公司高层发现房地产带动的五金行业也十分火热，于是下达任务给技术部，要求其立即着手搭建五金销售系统，货源已经谈好。得益于首席架构师之前优秀的架构设计，他发现只需要做一个卖五金的网站以及另外对微服务进行微量的调整即可满足老板的需求——因为卖五金和卖水果并无本质区别，他们涉及的环节几乎一致。加入五金售卖的系统架构图如下：

可见应用服务层代表是某一个业务应用，它代表的更多的是从需求出发的应用定义，而领域服务层则是业务领域按照自身的边界进行设计的一个高内聚的服务体。应用层通过协调和组合各个领域服务即可形成一个新的应用服务。《领域驱动设计》中明确指出，在设计领域服务时无需考虑表示层和持久层服务的东西。我在现实开发中总是遇到大量工程师按照产品的设计稿一溜烟的从上至下设计应用层服务和领域层服务，完全没有考虑业务领域的概念，导致后面微服务数量膨胀，功能重复度高。这种开发习惯代表的是《领域驱动设计》作者极力吐槽的一种模式——SMART UI “反模式”[5]。

推荐 Spring Boot 实战教程和源码：https://github.com/javastacks/spring-boot-best-practice

4.领域划分和微服务化

根据DDD理论，领域建模主要发生在领域服务层，各领域模块都应该是高内聚低耦合的，具有清晰的业务边界。本文不打算讨论具体的DDD建模（服务，工厂，仓库，实体，值对象，聚合等），这需要对DDD有较深入的研究，就目前所从事过的公司来看，似乎没有一家真正严格按照DDD进行项目代码设计的，就像摘要中说的，这对整个软件工程链路上的人员都有较高的要求。有机会可以单独写一篇关于自己对DDD建模的思考和建议，本文更多的是讨论高视角下的领域服务拆分，从而搭建一个低耦合高内聚的微服务体系。如果一定要将微服务和DDD联系起来的话，领域层的微服务就对应了DDD中的领域模块Module，每个Module由多个Service模式对象以及对应的模型对象（实体, 值对象以及它们的聚合）组成。

从《领域驱动设计：软件核心复杂性应对之道。》中我学到的主要有两块：领域设计思想和领域建模模式。本文更多的是对前者的运用，后者的对立模式是贫血模型，大家日常用到的也都是贫血模型，我也觉得贫血模型有存在的必要性，所以本文我们主要从其中借鉴一下领域设计思想。本文所描述的设计理念，并不影响具体的模型设计方法，我们仍然可以在每个微服务中使用DDD领域建模。

如何切分领域模块并没有一个明确的规则，不同的场景下可能相同的业务块边界也不尽相同。这里提几点领域划分的个人心得：

• 领域设计一定要有清晰的功能边界。一个领域服务对应了一个功能集合，这些功能