领域驱动DDD在签到场景落地案例之实践操作（三）

承接DDD概念初识第三篇，第二篇传送地址：领域驱动DDD在签到场景落地案例之架构模式（二）

为什么需要DDD（DDD的业务价值）

上面基于三层架构开发或者是没有统一设计思路的架构方式在代码演进过程中出现了各种问题，比如：没有统一共识而只按照自己想法写代码只要完成需求就ok，业务逻辑写到数据库执行过程中，系统创建初期设计的井井有条到了后期需求的不断变化使原来的设计面目全非。
使领域专家和开发者在一起工作，这样开发出来的软件能够准确地传达业务规则。当然，对于领域专家和开发者来说，这并不表示单单地包容对方，而是将他们组成一个密切协作的团队。

• “准确传达业务规则”的意思是说，此时的软件就像如果领域专家是编码人员时所开发出来的一样。
• 可以帮助业务人员自我提高。没有任何一个领域专家或者管理者敢说他对业务已经了如指掌了，业务知识也需要一个长期的学习过程。在DDD中，每个人都在学习，同时每个人又是知识的贡献者。
• 关键在于对知识的集中，因为这样可以确保软件知识并不只是掌握在少数人手中。
• 在领域专家、开发者和软件本身之间不存在“翻译”，意思是当大家都使用相同的语言进行交流时，每人都能听懂他人所说。
• 设计就是代码，代码就是设计。设计是关于软件如何工作的，最好的编码设计来自于多次试验，这得益于敏捷的发现过程。
• DDD同时提供了战略设计和战术设计两种方式。战略设计帮助我们理解哪些投入是最重要的；哪些既有软件资产是可以重新拿来使用的；哪些人应该被加到团队中？战术设计则帮助我们创建DDD模型中各个部件。
  就像其他高回报率的投入一样，DDD需要我们在时间和精力上都有所投入。但是，考虑到我们在开发软件的过程中经常遇到的各种问题和挑战，这样的投入是值得的。

软件开发者不应该只是热衷于技术，而是应该将眼界放得更宽。我认为不管使用什么技术，我们的目的都是提供业务价值。而如果我们采用的技术确实产生了业务价值，人们就没有理由拒绝我们在技术上的建议。如果我们提供的技术方案比其他方案更能够产生业务价值，那么我们的业务能力也将增强

领域建模过程

前面提到领域驱动设计包括战略设计和战术设计，领域建模从这两个层面展开

战略设计

事件风暴是一项团队活动，领域专家与项目团队通过头脑风暴的形式，罗列出领域中所有的领域事件，整合之后形成最终的领域事件集合，然后对每一个事件，标注出导致该事件的命令，再为每一个事件标注出命令发起方的角色。命令可以是用户发起，也可以是第三方系统调用或者定时器触发等，最后对事件进行分类，整理出实体、聚合、聚合根以及限界上下文。

运用限界上下文（BoundedContext）来分离领域模型。接着，在明确的限界上下文中发展一套领域模型的通用语言（UbiquitousLanguage）。

用黄色表示角色，用紫色表示读取信息，蓝色表示命令，橙色表示事件

角色 简单来说就是主语，可以是人物，可以是类似于定时任务的规则，可以是外部系统
读模型 （Optional）角色是基于什么信息做之后的决定的，不一定每步都有
决策/命令 原译Command，但叫“业务决策”可能更好理解，反正就是描述做了什么决定
事件 描述之前的决定触发了什么事情，或者说决策导致某东西的状态变了为什么。
举个例子：

1、 搜集用户故事（用户的原始需求），确定系统目标与愿景：先了解业务背景，主要由业务方和产品介绍，研发要着重记录对后面的领域划分有很大帮助
2、 业务场景分析：场景分析是从用户视角出发的，根据业务流程或用户旅程，采用用例和场景分析，探索领域中的典型场景，找出领域事件、实体和命令等领域对象，支撑领域建模。事件风暴参与者要尽可能地遍历所有业务细节，充分发表意见，不要遗漏业务要点。
3、 领域建模：根据场景分析过程中产生的领域对象，比如命令、事件等之间关系，找出产生命令的实体，分析实体之间的依赖关系组成聚合，为聚合划定限界上下文，建立领域模型以及模型之间的依赖。领域模型利用限界上下文向上可以指导微服务设计，通过聚合向下可以指导聚合根、实体和值对象的设计
a) 从命令和事件中提取产生这些行为的实体
b) 从实体中找出聚合根
c) 划定限界上下文、根据上下文语义将聚合归类

战术设计

在打好战略设计的基础之后，战术设计犹如使用一把精小的画笔在领域模型上描绘着每个细枝末节。我们需要把领域模型和代码模型建立一一映射的关系，将业务架构和系统架构进行绑定
1、 领域模型和代码模型建立映射关系
2、 写代码

每日签到领域驱动设计过程

【项目背景】每日签到是在金融app常驻的签到活动，为提升金融APP活跃度，通过发送钢镚奖励吸引用户每日打开app完成签到任务，且针对签到新用户、低频用户、流失用户提供次日签到成功奖励话费券大奖。所有用户在周日前签满则可参与瓜分大奖。
第一步：搜集用户需求，确定产品目标与愿景
每日签到主要为了APP的日活和用户增长业务提供奖励刺激的玩法， 产品运营初步把项目定位，所有人再通过头脑风暴的方式把想到的各种场景想法都填充上去，可以按照下面图上的模板方式：
为了什么需求、目标、结果等
提供什么服务、功能、策略、技术等
这个，指我们做的产品或系统
是一个什么样的产品、系统、活动等
不同于其他类似产品
我们的产品具有什么特点

第二步：业务场景分析
分析出签到活动中主要的业务场景，包括签到记录、签到功能、签到成功后发奖，实名风控、补签等
用蓝色表示命令，黄色表示业务流程，棕色表示事件

第三步：领域建模
1、从命令和事件中提取产生这些行为的实体。用绿色表示实体
2、从实体中找出聚合根
根据聚合根的性质从上面6个实体中找出聚合根
比如：通过签到玩法和不同的奖励刺激来完成用户促活，通过首页展示挽留弹窗和订阅消息来召回用户提升日活，签到成功后通过营销推广和任务来给其他业务线引流做转化，那么聚合根就是签到、奖励、任务、营销推广、订阅、挽留

3、划定限界上下文，根据上下文的语义聚合归类
通过签到和奖励共同构成用户促活域，通过订阅和挽留构成用户召回域，通过任务和营销推广构成用户转化/引流域，那么现在的限界上下文有三个，用户促活、用户召回、用户转化/引流

第四步：领域模型和代码模型建立映射关系

三层架构和领域驱动设计的区别

对比	三层架构	DDD领域驱动
数据模型	主要使用失血模型仅包括set、get方法，所有业务逻辑都在service 优点：层次清晰，各层单项依赖 缺点：业务逻辑层较重，边界不易控制，内部的各个模块之间的依赖关系不易管理，对象只是数据载体无行为	主要使用充血模型 优点：符合单一职责，面向对象 缺点：需要和领域专家划分业务，构建领域模型比较耗费时间
项目结构	严格三层结构，service层很重	领域是核心，依赖倒置原则 高层模块不应该依赖于低层模块，两者都应该依赖于抽象 抽象不应该依赖于细节，细节应该依赖于抽象
开发思路	技术人员很容易面向数据库开发	面向业务建模，面向领域开发
需求响应	前期快，后期慢且风险高 需求落地，研发可快速介入 需求的不断变化，原有的架构设计不符，开发成本高风险也高	前期慢，后期快 前期需要领域专家一起做事件风暴，领域建模，占用较多时间 后期领域模型已建立形成通用语言，业务沟通效率高、准确
系统维护	越来越难，因为三层架构没有严格的要求，理解不统一，开发人员在service层随意创建逻辑和对象导致系统管理困难，系统没有统一的文档阅读也不方便	思路清晰，因为前期耗费大量人力和时间梳理领域模型，再后期开发中可快速定位需求的所属领域 系统结构合理，代码即文档方便开发人员理解
架构属性	严格分层只允许某层和它临近的下一层发生耦合	松散分层架构，即某层可以与它的任意下方层发生耦合

什么样的业务更适合领域驱动设计

DDD计分卡：使用下表来决定你的项目是否值得做出DDD投入。如果你的项目情况在某行的描述范围之内，那么请在右边的列中记上相应的分数，最后将这些分数相加得到总分。如果得分为7分或者以上，那么，你应该考虑使用DDD了。

注释：
Ruby on Rails： 是一个可以使你开发、部署、维护 web 应用程序变得简单的框架
用户故事或用例流：一件用户通过系统完成他一个有价值的目标（买一罐饮料）的事就是“用户故事”或“用例流”
比如，谈需求的时候这样说：“用户往售货机每塞一个硬币，售货机都要显示当前该客户已经投了多少钱。当用户投的钱够买某一款饮料时，代表这款饮料的按钮的灯就会亮。如果那个用户按了这个按钮，售货机就放一罐饮料到出口，然后找零钱给他。

实施DDD过程中的挑战

1. 为创建通用语言腾出时间和精力
2. 持续地将领域专家引入项目
3. 改变开发者对领域的思考方式
   使用DDD最大的挑战之一便是：我们需要花费大量的时间和精力来思考业务领域，研究概念和术语，并且和领域专家交流，以发现、捕捉和改进通用语言。如果你想完全采用DDD来最大化业务价值，你需要做出很多努力，并且花费很多时间。事实就是这样的。
   要将领域专家引入你的项目恐怕也不是一件易事。但是不管有多么困难，这是你必须做的。如果你连一个领域专家都找不到，那么你根本无法对一个领域有深入的理解。当你找到领域专家的时候，此时开发者应该表现出主动。开发者应该找领域专家交谈并仔细聆听，然后将你们的谈话转化成软件代码。
   如果你所工作的领域和业务相去甚远，领域专家所了解的也只是一些边边角角，那么此时你应该将这种问题暴露出来。在我曾经工作的一个项目里，真正的领域专家很难找到，有时他们还会到处出差，我得等上好几周才能和他们开上一次会。在一些小型的公司里，领域专家通常是CEO或者副总裁，他们的事情太多了，这时你也别指望他们能做好你的领域专家。