利用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)提炼:抓住问题的本质(主要矛盾),提炼业务的核心领域,围绕核心领域投入重兵,其它的为支撑领域为核心领域提供支撑。业务分析人员、软件设计人员应对核心领域的细节多加关注,这些细节是系统成功的关键。
原文链接:http://www.jianshu.com/p/f7c1d9fde7a8

0 个评论

要回复文章请先登录注册