微服务能力层_DDD知识沉淀(一):浅谈微服务体系中的分层设计和领域划分

我们主张将其Web服务架构分为五层：基础设施层、领域服务层、应用服务层、网关层和用户界面层(表示层)

其中，各层的职能和作用为：

用户界面层：负责向用户显示和解释用户指令。这里指的用户可以是另一个计算机系统，不一定是使用用户界面的人(比如外部应用调用对应接口)。

网关层： 负责提供对外的HTTP服务或者其他应用层协议(这里是指OSI七层协议中的应用层，别混淆了哈)服务。

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

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

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

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

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

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

上层和下层只能有松散耦合(各自为独立个体，通过简单引用关联)。在某些微服务框架比如Dubbo中，可以把api包提供给上层引用即可。而Spring Cloud的上下层耦合更为松散，通过契约约定即可。前者的优点是调用者可以直接使用提供方定义好的契约和方法。后者的优点则在于最大限度的降低了耦合，避免在上层无限制的进行下层包引入。

这里重点说明应用服务层和领域服务层之间的关系。举一个例子：有一家上市企业A公司，靠卖水果发家，其首席架构师科学合理的按照D