DDD-快速hold住业务的利器

以前在小厂，由于业务场景与组织架构很小， 生产关系与链路都比较简单，业务的复杂度也相对较小。但在所谓的大厂（生活所迫)，业务场景较多且要支持业务的快速扩展，组织架构庞大，上下游的生产关系与链路巨复杂，所以研发在很大程度上都是在解决业务的复杂性的问题，一个如同“大泥团”般的项目，会给业务项目/团队协作/技术架构都会带来极高的复杂性，同时也带来了各种各样的问题，这些都让一个业务新人面对要接手的业务或服务一下子懵逼的(恭喜你，已经成功入坑了！），所以要想让一个新人快速上手业务并有产出，需要一个强大的指导工具与方法论的指引。

· 战略设计: 战略设计工具可帮助团队作出最有竞争力的软件设计选择和业务整合决策，并让团队在这些具有核心竞争力的软件模型中获取最大的利益。使用限界上下文的战略设计模式来分离领域模型，并在其中发展出一套领域模型的通用语言，如领域术语。

· 战术设计: 战术实施工具可帮助团队设计出实用的软件，对业务的运作方式进行精准的建模。将若干实体和值对象以恰当的大小聚集在一起，也叫做的聚合模式。

2.DDD作用

DDD可以帮助提高设计的有效性，并用来实现高价值的软件，也用来解决软件设计上的复杂度/扩展/开发成本等问题，在目前日益竞争的市场环境下持续交付出最有效的软件设计与实现。采用DDD带来的可能改变:

· 提高项目的成功率;

· 提升业务的竞争力，正确地对业务需求建模；

· 能比较轻松地对软件架构进行迭代演进并扩展.

3. 限界上下文

限界上下文是语义和语境上的边界，意味着边界内的每个软件模型的组件都有特定的含义并处理特定的事务，限界上下文中的这些组件有特定但上下文语境和语义理据。其中可以理解为限界上下文是一个问题空间以及这个问题的解决方案空间。

目前经常可以看到的几种架构风格:

· 事件驱动架构: 是一种以事件为媒介，实现调用接口者和接口实现者之间的解耦，事件驱动则是调用者和被调用者互相不知道对方，两者只和中间消息队列耦合。

· 响应式架构和Actor模型:  是事件驱动的一种实现方式，特别擅长处理多个客户端并发的向服务端请求服务的场景。如Reactor模式会解耦并发请求的服务并分发给对应的事件处理器来处理。目前，许多流行的开源框架都用到了reactor模式，如: netty、nio等，还有一种如Akka的actor模型。

· 具象状态传输(REST):  描述了一个架构样式的互联系统。REST约束条件作为一个整体应用时，将生成一个简单、可扩展、有效、安全、可靠的架构。由于它简便、轻量级以及通过HTTP直接传输数据的特性。用于web服务和动态Web应用程序的多层架构可以实现可重用性、简单性、可扩展性和组件可响应性的清晰分离。

5.子域

DDD项目中总会碰到很多限界上下文，这些限界上下文一定会有一个成为核心域，而其他的限界上下文之中会存在许多不同的子域名。子域是整个业务领域的一部分，子域代表的实施一个单一的、有逻辑的模型，大多数的业务领域过于庞大和复杂，难以作为整体来分析，因此我们只关心那些必须在单个项目中涉及的子域，子域可以用来有逻辑地拆分整个业务领域，通过DDD来创建子域，它将会被实现成一个清晰的限界上下文。

· 共享内核: 两个团队之间共享着一个小规模但却通用的模型，团队必须要共享的模型元素达成一致，有可能它们当中只有一个小团队会维护、构建以及测试共享模型的代码。

· 客户-供应商:  供应商位于上游，客户位于下游，支配这种关系的是供应商，因为它必须提供客户需要的东西。客户需要与供应商共同制定规划来满足这种预期，但最终却由供应商来决定客户获得的是什么，什么时候获得。

· 跟随者: 关系存在于上游团队和下游团队之间，上游团队没有任何动机满足下游团队的具体需求。由于各种原因，下游团队的也无法投入资源去翻译上游模型的通用语言来适应自己的特定需求，因此只能顺应上游的模型。防腐层就是下游团队好用的工具之一，是最具有防御性的上下文映射关系，下游团队在其通用模型和位于它上游的通用语言(模型)之间创建了一个翻译层次，隔离了下游模型和上游模型，并完成两者之间的翻译。

· 开放主机服务: 定义了一套协议或接口，让限界上下文被当作一组服务访问，该协议是开放的，所有需要与限界上下文进行集成的客户端都可以轻松使用它，通过API提供出来服务并且都有的详细的说明文档。

· 已发布语言:  是一种有着丰富文档的信息交换语言，可以被许多消费方的限界上下文简单地使用和翻译。需要读写信息的消费者们可以把共享语言翻译成自己的语言，最好的例子就是SDK。

上下文映射集成方式

· 基于SOAP的RPC: 目前主流的Dubbo/HSF的框架都是典型的例子，基于SOAP的RPC的设计思路就是让调用另一个系统的服务如同调用同一个本地过程或方法那样简单，SOAP的请求需通过 络传输才能抵达相关系统，成功执行后并返回结果。但这种集成方式缺乏健壮性，这就是为什么RPC框架中有很多容错设计的原因。

· RESTful HTTP: 注意力集中在上下文之间交换的资源，有POST/GET/PUT/

DELETE等操作，支持REST接口的服务端限界上下文应该提供开放主机服务和说明文档。同样这种方式也有可能因 络或服务提供商故障， 络延时等，错误或异常的全链路跟踪与日志也是很困难的。使用REST设计错误是直接把模型中的聚合暴露出来。

· 消息机制: 在使用消息机制进行集成时，很多工作都是通过客户端限界上下文订阅由它自己或另一个限界上下文发布的领域事件来完成，使用消息机制可以消除阻塞调用，一个领域消息可被一个或多个订阅方消费，常用的消息中间件一般可用于消峰/解耦，但也可能造成领域事件过多，消费过慢等情况发生。

· 实体: 一个实体模型就是一个独立的事物，每个实体模型都拥有一个唯一的标识符，可以将它的个体和所有其他类型相同或者不同的实体区分开，并且每个实体都有一个生命周期，将实体与其他建模工具分开的主要因素是它的唯一性;

· 值对象: 值对象是对一个不变的概念整体所建立的模型。在这个模型中，它没有唯一标识符，而是由类型封装的属性对比来决定相等性，一个值对象不是事物，而是被常常用来描述、量化或者测量一个实体;

· 聚合根: 每个聚合的根实体控制着所有聚集在其他的元素，根实体的名称是聚合根概念上的名称，每个聚合都会形成保证事务一致性的边界。意味着在一个单独的聚合中，在控制被提交给数据库事务事，它的所有组成部分根据业务规则保持一致。一个聚合也要建立概念上的完整模型，事务一致性。

SWOT分析法

swot分析方法是根据项目/产品所拥有的资源，进一步分析项目/产品的优势与劣势以及企业外部环境的机会与威胁，进而选择适当的战略。SWOT分析是一种综合考虑内外部条件的各种因素，进行系统评价，从而选择最佳经营战略的方法。在每个版本的迭代周期中，在做需求分析/规划/评审的时间点，利用SWOT分析法工具可以让业务或产品的发展方向更加聚焦，将研发资源投放到真正该投放的方向。

· 优势: 领先于对手的业务或项目特征;

· 劣势: 落后于对手的业务或项目特征;

· 机会: 可以发挥项目优势的要素;

· 威胁: 存在于环境中并可能给业务或项目带来问题的因素.

任务识别与工作量估算

任务识别和工作量估算是做敏捷迭代很重要的一个步骤，时间代表了人力，代表了金钱，估算的准确度直接决定了版本发布的时间偏差。这里在平常的敏捷迭代的评估是基于用户故事下的，粒度较粗，估算稍不准确，这里使用了领域事件/命令/聚合+简单复杂程度等领域驱动设计的概念作为估算度量指标，使其更加准确，更加符合实际。

– END –

往期回顾

◆高可用架构设计之无状态服务

◆Twitter 广告平台实时计费系统的架构增强之道

◆使用契约测试提高分布式系统的质量

文章知识点与官方知识档案匹配，可进一步学习相关知识Java技能树使用JDBC操作数据库数据库操作92637 人正在系统学习中