DDD架构设计知道-降成本-限界上下文拆分（4）

前面的一节，我们说领域模型分析设计“迭代三步走”中.第一步，定义合理的限界上下文，第二步，明确限界上下文之间关系。第三步，确保限界上下文内部设计遵循高内聚低耦合原则。这三步的每次迭代目标都是由底向上精炼抽象的核心领域业务模型。由顶向下具化构建核心领域业务逻辑。
     首先，我们在分析一个全新不熟悉的业务领域时，我们通过什么工具来分析定义合理的限界上下文呢？亦或是旧单体业务又如何合理分析定义拆分限界上下文呢？又或之前系统虽然分隔了限界上下文，但是内部业务知识，分析设计知识已经流失，那么如何查漏补缺重建领域模型呢？
   有的同学肯定说我们要像“庖丁解牛”一样，把这头“牛”大卸八块分割好。但殊不知庖丁的功夫，是利用的已有“目无全牛”的经验 。那是对熟悉已知的事物，可以做到快速全面拆解。而对于第一次的新项目或事物这是不合适的，因为根本不可能全面透彻的了解全貌。甚至有时候“细枝末叶”的区域，领域专家都不一定做得到。
   那么我们如何开始对需求进行分析设计，最终形成业务模型转化呢？主要是“从特殊到一般的抽象，再从一般到特殊的实现”。特殊是我们这个时代的偶然，有人可能觉得不对。“一般”才是我们这个时代的主旋律。其实并不是，殊不知我们每个个体都是偶然的出现，需要非常多的条件才可以进化如此。人类在地球的产生也是偶然的等等。所以我们每个人都不同，也都是独一无二的特殊的。那么要让平时我们的人类活动（需求业务）变得有序。那更是一种特殊性,因为世界本身无序混沌的。从整体来看有的同学又认为，那是不是我只要现实世界的“特殊性”用计算机直白实现这种“特殊性”不就完事了？可以省去了中间的现实抽象一般性再到计算机实现的一般性转变呢？也有很多同学就是这样做的。比如堆叠的“屎山代码”，各种难以维护的到处复制粘贴，懒到不抽象直白实现现实需求等等。都是缺少这个思考过程，并付诸于实现所致。都是为了赶进度快速的模仿，不思考反思，只是完成一个个单一功能而做的“短期工”.当然这也是“资本家”剥削压榨剩余价值的结果（要求赶工）。
     当前主流的DDD分析法有两种一种是事件风暴。另一种就是用户故事。有同学初看DDD时候，听说过一些“事件风暴”分析法。他宣扬的使用大白板，多色贴纸及多方人员共同参与的工作坊（workshop）形式。就感觉这个前提下很多项目的资源并不足以支撑这样的工作坊，然后就自认为这个方式并不适合。其实简单的说它只是希望多角色人参与集思广益。
其实事件风暴主要的方式并不是需要很多的人，甚至有时候只要你对业务有所了解，自己玩转“事件风暴”也是没问题的。其实事件风暴就是大家小学都会的写事件记叙文的六要素，“时间”，“地点”，“参与者”，“事件的起因”，“事件的经过”，“事件的结果”。我们知道王阳明说过“心即理”，其实我们并不用向外求太多，这些你静思就可以了解个七七八八。更何况小学写作文的时候，也不是群体协作，也都是由你独立完成。这少不了你对经历的仔细观察和体悟。有兴趣可以参考我写过的一篇事件风暴与事件六要素的异同文章（https://mp.weixin.qq.com/s/9CL2CmA610MLt
     那么另一个用户故事就是从需求中提炼5w1h（when，where，who，why ，what，，how）的方法。它属于对原始需求的规则性细化描述。从中我们可以对于每一个需求分解完成us（用户故事）。参照模板进行书写变成可规范化的结构短语。从中提取实现需求所需的业务知识。
    有人说事件风暴与用户故事两种方式非此即彼。其实持有这种二元论的同学不在少数。我在项目中的实践认为，如果作为开发人员占主导地位的科技型公司，纯技术驱动的公司应该先用事件风暴勾勒出整体业务脉络轮廓。再使用用户故事进行填充细化需求分析。才会将业务需求活灵活现的呈现出来，跃然纸上。有整体有细节的需求描述才是完美分析设计的前提，为后续的限界上下文拆分打下坚实的基础.

业务驱动型公司还是应该先由产品经理梳理好用户故事地图进行传统的用户故事目标价值导向的需求管理方式。而由技术人员在进行事件风暴的分析验证和补充。来实际指导开发。

   下节我们来看下绝大部分公司以传统用户故事为引导，事件风暴结合的分析方式。