利用Spring Cloud实现微服务(二)--领域驱动设计

在开发一个微服务之前,我们要设计微服务。设计微服务和领域驱动设计(DDD)有密切的关系,DDD有助于我们设计微服务,所以我们这一节主要讲下领域驱动设计的基本概念、建模方法、架构等,以对我们设计微服务提供指导。

领域驱动设计DDD是目前比较火的一个软件架构术语,在我看来,这个其实是业务驱动IT的一个具体体现。DDD的核心思想是在做IT设计之前,要对业务有深入的理解。DDD告诉了我们领域建模的方法并理论化。

1. DDD的基本概念

1)领域:领域就是一个组织所做的事情以及其中包含的一切,每个组织都有它的做事方式和业务范围,这个业务范围及在其中所进行的活动便是领域。对领域最了解的是业务专家,而不是IT人员。

2)模型:对领域的抽象和提炼,是对领域问题的思考过程的总结,由业务分析人员完成。模型承上启下:向上,业务分析人员需要用模型和业务专家沟通;向下,业务分析人员用模型指导软件设计师进行设计并开发软件。模型的首要要求是一致性,同一模型必须是一致的、保持不变的。

3)上下文:可以认为是模型的势力地盘,我的地盘我做主,大家要各司其职,不要越界。使用一个模型之前要进行哪些操作,使用一个模型之后要进行哪些善后。每个模型都有缺省的上下文,当业务比较复杂,特别是要和存续系统对接时,模型的上下文边界就很重要。

2. 领域驱动设计的战略建模(原则)

也可以说是原则,但我更愿意称之为战略建模,就是在项目开始要从宏观的层面划分清楚业务领域,各业务领域能各自为政(限界上下文),独立进化,对外又能形成一个统一的有机体(上下文映射)

1)限界上下文:

把模型的上下文限定在一定范围,模型负责哪些事情,不负责哪些事情有清晰的定义。界定模型的上下文的原因是保持模型的一致性,不会受外界因素的干扰。在《领域驱动设计》一书里,将限界上下文比喻成细胞膜,很形象:”细胞膜不仅仅能把细胞内部和外部区分开,而且还能决定通过的物质“。

一般根据下面的因素界定模型的上下文:团队的组织结构、现有的代码库模块的划分、数据库的Schema等。推荐的做法是为每个领域创建一个独立的模型,该模型的上下文是该领域或该领域的子集。

2) 上下文映射:

描述不同的上下文之间的交互关系。业务领域之间不是老死不相往来,相反,业务领域之间存在各种各样交互。交互有下面的类别:

      a)共享内核:两个或多个限界上下文共享同一模型子集及模型相关联的逻辑、代码。团队之间需要统一共享,并且对共享内核的修改要征得另外团队的同意。

      b)客户-供应商关系:两个限界上下文是上下游的关系。处于下游的限界上下文(客户)严重依赖于处于上游的限界上下文(供应商)的输出,比如在电商领域,报表限界上下文严重依赖于在线购物限界上下文的输出(输出会保存到数据库里“客户”和“供应商”应定时安排会议,”客户“提交自己的需求,”供应商“对”客户“的需求进行排期开发。“供应商”会开发一些自己不需要但是“客户“需要的功能和接口。接口是联系“客户”与“供应商”的纽带,需要好好维护。

      c)顺从者:在客户-供应商关系里,当供应商没有意愿满足客户的需求时,客户只能被动接受供应商提供的模型和接口。供应商毕竟有自己要处理的事情,不可能靠“利他“理念推动供应商一直满足客户的需求。”利己“是人的天性。对于“客户”,可以走的一条路是自力更生,创建自己的模型满足自己的需求,并逐步减少对“供应商”的依赖。一旦”客户“有了自己的模型,需要防崩溃层进行对”供应商“提供的接口进行翻译转换。

      d)防崩溃层/反腐层/缓冲层:当客户-供应商关系变为”顺从者“关系,或者需要和存续系统进行交互时,需要防崩溃层对上游提供的信息和数据做出翻译,类似于《设计模式》里的Adapter。“客户”的防崩溃层通过调用“供应商”提供的服务来获取所需的数据或信息,经过防崩溃层的翻译、转换、适配,转变成和“客户”端内模型一致的数据。

     e)隔离通道:当两个系统之间没有或者很少交集,或者没有上下游关系时,或者系统之间集成的难度很大而价值很小时,就可以考虑隔离通道。每个系统都可以用如一个大型企业里的人力资源领域、供应链领域、社区领域。当我们拿到一个新的需求时,我们应该思考可否把它划分为两个或多个没有相通之处的部分。如果可以,我们可以创建独立的限界上下文,并独立建模。

     f)开发主机服务:当有上下游关系,不论是在客户-供应商或者顺从者关系下,作为供应商需要将和外面限界上下文交互的实体、逻辑包装成服务开发出去。应该定义一种协议,并将该协议开放出去,这样其它上下文都可以通过该协议访问。值得注意的是,当有特殊的需求,需要客户端自己采用防崩溃层进行翻译,而不是扩展协议,以保证协议的简单和连贯性。

     g)提炼:抓住问题的本质(主要矛盾),提炼业务的核心领域,围绕核心领域投入重兵,其它的为支撑领域为核心领域提供支撑。业务分析人员、软件设计人员应对核心领域的细节多加关注,这些细节是系统成功的关键。

3. DDD的战术建模

战术建模是指将不同的领域对象进行分类,并为之建立模型

1)实体:拥有唯一的标识符;标识符在生命周期里不会发生变化;其它属性在生命周期内可以发生变化;需要被跟踪

实体是DDD里一个很重要的概念,在DDD的开始就要定义实体,围绕实体开展工作。

实体可以采用普通旧式Java对象(PO JO,Plain Old Java Object)描述。

2)值对象:Value Object,在该对象的生命周期内,属性不会有任何改变的对象;值对象是不可变的,是可以共享的。值对象应该很小,也可以很简单。

从实现上来讲,一般是值对象设置为类的私有属性,通过构造函数传入值对象具体的值,当需要一个不同的值时,重新在构造函数里传入不同的值创建新的对象。

3)服务及服务对象:在领域建模的过程中,我们会发现,有些活动不属于任一个实体或值对象的职责,反而实体或值对象是这些活动操作的对象,这些活动对整个领域来说有很重要,把这些活动安排到任何一个被操作的对象里,都会破环该实体或值对象。从面向对象编程的视角,我们会把这些活动归类到一些对象里,这些对象叫服务对象,这些活动叫服务。

服务对象不具备内部的状态,它的唯一目的是提供操作领域内实体或值对象的活动。实体或值对象属于服务的被操作对象,从语意上讲,实体或值对象属于宾语,而不是主语。例如:生成报告,这个活动里,报告属于宾语,属于被操作的对象,因而生成报告不属于报告的职责,要单独创建一个服务对象来执行这一活动。

服务也属于领域模型的一部分,大部分的服务都会在DDD架构模型里的领域层。

4) 模块:通过高内聚、低耦合的原则将领域划分为不同的模块

实际操作中,一般把操作相同数据的或完成同一业务功能的部件划分到一个模块

模块的划分对于设计来说粒度还是太粗,所以需要将模块继续细分到聚合和聚合根

5) 聚合和聚合根:聚合用来定义对象的所有权和边界。

聚合:针对数据变化可以考虑成一个单元的一组关联的实体和值对象。比如,要删除时,会一起被删除;要创建时,会一起被创建。

聚合使用聚合根将内部和外部的对象划分开来,聚合根是一个实体,是外部可以访问的唯一对象。

划分聚合时要考虑的原则:

     a)数据的一致性:针对数据变化可以考虑成一个单元。执行上,聚合外部的对象只持有对根的引用,而不能直接对聚合内的实体进行访问和更改。对聚合内部的实体和对象的访问必须通过根对象。在一个聚合内部,根可以修改其它的实体,但这是可控的。如果根从内存中被删除,聚合内的其他对象也将被删除。如果一个聚合中的对象被保存在数据库里,通过查询来获得的只有根对象,其他的对象只能通过从根对象出发的导航关联关系获取

     b)聚合应尽量小,尽量简单和容易理解,而不是尽量完整。所以,对于聚合,一个工作思路就是对聚合内实体的关系进行简化,尽量把关系对应成1对1的关系,比如通过删除非基本的关联关系、增加约束等方式

6) 工厂:创建对象的方法,将聚合作为一个整体来进行创建。可以参见《设计模式》里的工厂模式或者抽象工厂模式。

工厂也是领域设计中的一类对象,工厂提供一个接口封装复杂的封装过程。

当聚合里的实体组装很简单,或者一个对象的创建不会涉及到其它对象的创建,可以采用根实体的构造函数创建。

7) 资源库:也是模型设计里的一个对象,用来保存可用的聚合,并返回聚合根的引用。注意资源库与存储区的区别。资源库属于领域区,封装了对数据操作的细节,对外部提供一个接口,隐藏了对数据操作的细节。而存储区指数据库、文件等持久化存储设备,处于基础架构区。

工厂和资源库、存储区的关系:


4. DDD的多层架构

同其它架构方法类似,DDD也是多层架构。DDD的多层架构分为了:1)UI层;2)应用层;3)领域层;4)基础架构层。理解这几个层级,对于下面开展微服务的工作很重要,所以要搞清楚这几个层级的定位。

1)UI层,顾名思义,就是用户界面层,用以提供和和用户交互的界面。

2)应用层:这个比较容易和其它架构里提到的应用混淆。在DDD里的应用层,主要负责工作流程的编排工作。用服务的语言来讲,应用层可以称为是服务编排(传统的SOA)层或者服务调度层(微服务)。

3)领域层是领域驱动设计中的一个很重要的层级,在这几个层级中,只有领域层负责领域模型。领域层包括实体和业务逻辑。领域层实现了服务(实现业务逻辑)、资料库(对数据实体进行CRUD操作)等

4)基础架构层:这个也和其它架构里提到的基础架构有区别。这里的基础设施不仅仅包含计算、网络、存储等硬件设施,还包括应用的基础架构,如操作系统、数据库、消息队列等。基础架构为上层逻辑的实现提供支撑,并存储数据

对DDD的回顾就到这里,下一节我们会基于DDD的思想设计一个网上叫车的微服务,开发并注册到第一节开发的Eureka上,敬请期待

推荐阅读更多精彩内容