一、背景最近有微信朋友在公司内部分享的时候有人问领域划分的规则是什么？意思就是你怎么知道一个领域需要划分哪些子领域？有没有依据，是凭直觉吗？本文将重点讨论下这个比较现实的问题。同时根据网友的试读建议本文进行了思维导图的总结，可以保存收藏。本文先找人进行了试读，有大佬提出了一些建议，为了让本文更容易让人理解，这里我们不再具体讨论领域模型、子领域、限界上下文和聚合的概念，而是聚焦于对一个宽泛意义上的领域来划分，另外当你真正深入领域划分过程的时候，其实这些词在某些情况下是等同的，比如上下文，领域，子领域这三个词。所以对于划分出来的划分方案可能就是一份文档，一个对于应用架构落地的指导性方案。那么这时候，领域可能是一个部门负责的，可能是一个平台系统，可能是一个单独的微服务，也可能是更细致上的模块。最终，当你觉得概念很难理解的时候不妨先放一下，去真正体验一下领域驱动设计中的统一语言在现实情况下的应用场景。二、领域划分的依据现在我们先直观的回答这个问题，我这边从以下个方面来阐述一下领域划分的依据，可能不够全面，如果有其他依据欢迎交流讨论。2.0 领域划分依据的思维导图2.1 基于领域模型的对象关系在进行领域建模的时候我们会完整的构建一张对象关系图谱，有些对象很明显的属于某一个范围，这个范围相当于对这些对象的一层抽象或者总结，比如SkuBO,SpuBO,SkuSnapShotBO等。这些虽然没有表达商品的概念也没有显示的定义ItemBO 但是我们可以很容易的通过关联关系来把他们画成一类。你可能会觉得这样的划分不就是主观意义上的吗？或者这本身就是凭直觉去做的。那我们再看一下每个对象的业务操作和其本身的一些行为是否会影响其他对象，是不是强关联的。很多业务对象事实上都有关联关系，但是在业务流程和交互上有先有后，有时候做一件事情可以延迟做另外一件事情然后去修改或者调整数据关联关系，这样就形成了一定的上下游关系或者依赖关系，这是一种依据。在对象的关联关系中如果存在一对多的情况或者存在多级关联关系的那种比如省市县或者系统-菜单-按钮的这种情况，或者是一个主单子对多个单据详情列表，这种我们可以自然的去把这些对象单独放一起，如果存在别的对象要引用一对多的多方就要考虑是否要通过一方去进行引用遍历，或者说别的对象也可以把多方的这个对象划分到对应领域里，类似于都有关系的那种，那么在操作上一对多的情况下肯定是希望在一次操作就可以完成的。如果这个对象也参与在这个操作中就可能存在这个对象跟一对多的这俩对象是一种聚合关系或者可以划分为领域内对象。当然有些对象是关联对象被显示的表达出来了，比如UserRoleRelationBo这种的，这样的关联关系本身也算领域内的对象，可以附庸在UserBO或者RoleBO的领域上下文中。2.2 基于数据模型的对象关系从数据模型上不是特别能看出来领域划分的依据，但是我们可以从中找到一些线索，比如一些表之间跟另外一些表之间本身有些数据的流动关系，或者依赖关系。或者我们通过几个被依赖的表去发现被依赖的表本身就代表着这个表可能就是一个核心表，那么核心表对外而言就只需要通过其ID或者业务标示字段进行关联，内部的表都可以通过这个表的ID来遍历找到。一个特殊的案例就是我们会因为性能等方面的原因来打破数据库范式的约束，比如做冗余，但是这个冗余的字段却很明显的不能当作表间关系的依据。一个超过10张表的e-r图从布局上就可以看出这些表之间的亲缘关系。2.3 基于业务流程的交互关系尝试划分领域的一个最好的实践就是去了解业务流程，通过时序图，通过流程图我们可以从不同的节点事件来表达这些节点事件的关联关系，比如外卖，对于用户来说他做的就是浏览菜单下单支付然后拿外卖，在用户操作的这个领域来说他就只有几个节点，这些节点还包括商家接单，商家把单子告诉厨房，厨房准备菜品，做好了外卖员要么在取餐的路上要么在等餐的路上，或者在送餐的路上。那这个例子就告诉我们一个业务流程如果我们不分割为多个领域的话我们几乎无法完成一整套的操作。这期间其实也涉及到了一个上下文或者数据流的变化，比如从订单上看用户订单到商家订单，再到外卖送餐订单。这个订单如果是一个的话其实是需要多个角色一起完成的。比如骑手准备送餐了，那么系统可能会告诉骑手走哪条路最快，这个骑手按照路线走的过程其实放大了看就相当于一个问题领域，就是最佳路线选择的问题。从全局看的话，外卖都追求快效率高，所以对于平台方而言各个领域内部的处理流程就成了预测建模和提效的依据了。所以可以得到一个结论领域的划分依据是可以通过业务流程中的不同的节点的关系度和业务数据流去分。2.4 基于抽象复用的要求在java中万物皆对象，包括女朋友。所以很多时候有些领域是经过实践探索的，那么对于后来者来说领域的划分就简单很多了，不是凭感觉，而是我就是这么抄过来的。那么对于划分领域的这个人是否真正的从业务出发去划分谁也不知道，就是说这个领域在当前业务中是肯定存在的，比如下单优惠，支付优惠，营销策略等等。重点在于营销和优惠是不是在业务流程中存在多次，如果说业务刚起来有优惠的场景。那么此时就去识别优惠领域，构建一个营销优惠平台可能就不太合适。那么，再看一下，假设某公司有多个业务线，业务上都做了营销优惠相关的逻辑，但是业务成交量却上不去，业务线之间的关联关系却不紧密。那么这个领域还是否需要独立出来做单独的领域建模呢？注意我这里举的例子是把领域看作看作系统应用服务级别的而不是模块上下文级别的。那么终究有一些其他存在感比较强的横向应用场景，比如权限，审批这种的。如果一个大型系统没有权限和审批的话那系统可能就千疮百孔了。另外一方面企业相关的IT系统基本都比较大，同时微服务和分布式也催生了很多相对小粒度的系统，但是这并不意味着每个系统都要背负一套权限模型或者审批流，所以绕来绕去还是需要建设一个相对统一和通用的支撑系统来解决每个系统的共性的业务的依赖功能。其他的例子也有不少比如工具，中间件等，但是都是基于抽象复用和解耦的目的去考量和划分领域的。2.5 基于角色和职责的定位前面说的场景也遗憾了这个依据，在这一小节中我们可以看到因为分工和职能的问题导致的领域划分变得时而简单时而复杂。因为角色和职责在某些情况下会分的特别详细比如线上出现了一个bug，不大不小的。要问责，领导要背多少个百分比，开发，测试，产品要分多少。但是有时候就会发现很多人会做一些“分内之事”，怎么说呢，就是说职责上和角色上并不属于自己去做或者去推动的事情而去做了，那么此时领域的划分就变得模糊了，说白了可能从别的视角或者在别人看来是狗拿耗子了。在具体事项上因为角色或者职责等的因素导致划分不清晰其实也很多，说白了就是可能因为妥协或者坚持才发现结果的对错。在这一方面上看，因为某些问题导致的划分不清晰可能是没有统一的标准或者规范，就是说没有个标尺来说明谁做这个事好。比如说当前是因为某原因在B领域系统里帮A做了A领域系统里的部分功能，从当前看是复合当前利益的，但是从长远看并不合理，那么就可能会出现一些情况，B依然承担了这个职责，系统正常运行。A变得非常复杂让B很难受。B去掉了这个职责，让A自己做。或者B在升级的过程中因为这部分职责让B自己很难受。所以在多个领域之间其角色和职责会代表着这个领域的范围，有时候帮助我们在划分领域的时候寻找有角色和职责相关的因素去找最好的划分方案。根据大佬的意见是在这个维度上可以通过企业架构(EA)来划分，说白了领域划分可能会受到利益相关者的干扰，即使你觉得非常合理非常适合演进的领域划分方案其实可能并不是最合适的，起码对于处在各个业务架构下的带头老大也通常不会认可这种方案。2.6 基于团队协作的方式现在我们从团队或者合作方的角度来谈领域划分相关的话题，因为团队协作其实也不仅仅包括公司内部的团队和部门，毕竟关起门来好商量，在2.5的描述上看上下游都是兄弟嘛。那么如果部门变得比较大是兄弟公司级别的或者业务线级别的可能就是堂兄弟了。那现在我们看一下一个更广泛的团队协作方式，就是跨企业的合作，比如互联网中小型公司对接支付宝，微信或者银行，毕竟人家是大佬，跟你不存在太多好商量的余地，只能按人家的标准和规范来。那么为了做业务所以只能在自己的业务领域中找一个可以做适配的领域来帮忙对接。又或者是我本身没有这个领域的能力，但是我有钱，我可以买服务，买系统来实现这个业务依赖的功能。此时可能已经不需要你去费尽心思去分了，老板已经搞定了。但是这不意味着领域划分就结束了，而是说这个领域相关的模型和业务接口实现什么都起码有一套了，自己要做的就是弄个适配模块来代表这个领域的能力，比如第三方系统的对接，下游对接的防腐层等等。现在总结一下就是因为团队和客户供应商的关系会让相关领域的划分变得简单，在eric的书中很多战略上的模式也说明了一些领域划分的依据，只是不是特别明显。三、领域划分的规则或者原则上面从各个方面来阐述来一些领域划分的依据，那现在我们总结一下相关的规则或者原则，领域划分的规则其实跟聚合或者上下文划分的规则很类似，基本上大同小异，小异的地方等有时间再分享下。因此我也重点看了张逸老师的《解构领域驱动设计》的书，把其中关于上下文和聚合相关的原则拿过来简单说明一下。3.0 领域划分的规则或者原则思维导图3.1 单一抽象层次原则这个原则其实要求做领域划分的时候不可以抽象出多个相似的领域，比如营销和优惠，这两个可能就是相似的领域，或者说优惠是在营销领域下的一个层次的抽象，那这样的话我们可以用这个原则来检查一下划分的领域有没有可能存在相似和重复。当然另外一方面也可以保障我们可以识别大多数的重要领域。3.2 奥卡姆剃刀原理这个在书里说的意思是在划分上下文的时候不要做的太细，太细的话就存在多个层次的内容反而无法更好的切分上下文，那么在领域层也类似，说白了，通过这个原理可以让主观的划分更有能动性，也更能给出划分的理由。即使是拍脑袋划分的，能从中取出核心的领域名称并给出具有说服力的理由也算一种划分方案。3.3 最小惊讶原则这个原则说的是在真正懂行的专家里或者有经验的大佬面前如果你的划分挺合理的话那么他们不会感到惊讶，可能会会心一笑。反之就会觉得有需要改进的地方，或者再讨论讨论。所以在领域和上下文的划分上来看，如果划分的比较合理那么就没有太多争论的必要了。3.4 正交原则这个正交原则其实可能有点不太理解或者不容易应用，在领域划分方案出来之后可以通过一些业务流程来看一下领域内的聚合实体服务等是否跟别的领域内做的事情相似或者一样，如果存在的话说明还可以继续优化。直到每个领域做的事情都足够唯一或者职责单一，到合适的正交维度即可。如果过度的追求正交和职责单一可能会出现3.1的情况。3.5 多数派原则这个原则是我在群里面聊的内容的一个总结，简单解释一下，就是可以从统一语言或者领域名称中找一些线索，比如我们有很多业务流程，有很多用例或者用户故事，那么这些文档和业务中哪些出现的名词或者动名词最多这个就可以作为一个领域。目前看这是一种最简单的领域划分原则了，也就是说你可以从脑海中过一遍所有业务流程，接口流程，调用时序，从统一语言上去统计哪些词语是最常出现的，这些词语代表了哪个维度的领域，是核心领域还是通用领域，还是依赖领域等等。那么可以把这些词语单独摘出来去划分，当然也可能有最多的排序，比如出现词语最多的有20个，但是里面可能有重复的，不够正交也不够单一抽象，那么可以用排除法一一去舍掉看是否是最好的领域划分方案，类似于手动寻找最优解。四、领域划分的方法从现在看领域的划分可能比聚合和上下文的划分更有难度，领域本身涉及的维度其实是多维的，所以在正交上只是选择某一维度去划分，说白了就是在边界上其实领域是更模糊的，有时候上下文就可以代表领域，但是领域其实可能不能跟上下文去划等号。所以领域划分的话其实是对时空间的划分，比如生态系统，12306购票系统，这些系统其实是跨空间在时间上并行的。业务流程是源源不断的通过各个领域。所以通过上面的一些依据，规则或者原则能帮我们区分领域的问题空间和解空间，以及将这些业务流程从时间维度上来验证划分的结果是否合理。五、总结这个话题其实也让很多学DDD的人又多了一个问号，但是如果这个话题讨论清楚了那么我们对于DDD和领域相关的知识理解又深了一些，本文也仅通过自己的所思所想表达一下这个话题相关的内容，如果有补充的或者哪里不对欢迎讨论。小编后记：作者总结了这么多，佩服。但类似2.1，2.2似乎有些面向数据设计，再反向找领域对象。欢迎读者交流！

大家好，我是业务组件部的神帅，很高兴大家来听我的分享。下面我将通过6个小节给大家阐述一下本次的分享内容，首先将给大家介绍一下DDD的相关概念和理论，然后通过架构风格来衔接实战内容，好了，话不多说，我们开始。为什么要了解DDD，DDD能给我们带来什么样的好处呢，本小节将着重介绍DDD相关的理论内容以及与设计模式的对比。这样可以更好理解DDD，是因为我在学习DDD之前先学了设计模式，是在大学的时候看了一本书叫《设计模式之禅》，今年看了eric的书《领域驱动设计》，发现里面很多模式都可以用设计模式的方式给固化下来，当作一个DDD模式去学习，这样理解起来也简单很多。从软件开发角度来讲有11种开发模型，有4种开发模式，其中就有领域驱动设计，也是本次分享要重点介绍的内容。很多人都在定义DDD是？或者说DDD不是什么？除了上面的定义问题也有人说DDD是一种建模方法？其实我个人倒觉得DDD是类似于武功心法一样的东西，可以提升开发功力，改变看待需求的角度,不局限于理论和架构。借用万物皆对象的说法，就是万象皆领域。大家都知道DDD起源于国外，是一种比较新颖也比较难懂的理论方法。有些大佬对DDD奉为圭臬，有些则嗤之以鼻，另一些就无所谓，不用DDD解决不了上面的问题吗？确实可以解决，但是依然很复杂，就是需要花费很大精力去解决这些问题。而DDD要解决的问题就是降低软件复杂度，分离技术和业务需求，进行领域建模沉淀可复用可扩展的业务模型和工程代码。先回顾一下设计模式有哪些内容，概括起来就是23+6，23种设计模式加6大原则

2．架构映射阶段架构映射（architectural mapping）阶段根据全局分析阶段获得的产出物，即价值需求与业务需求，分别从组织级、业务级与系统级3个层次完成对问题空间的求解，映射为架构层面的解决方案。整个架构映射阶段与主要工作流的关系如图3-3所示。通过全局分析阶段完成对问题空间的探索后，对解空间架构层面的解决方案映射，几乎可以做到顺势而为。通过执行组织级映射、业务级映射与系统级映射这3个过程工作流，分别获得组织级架构、业务级架构与系统级架构。在执行组织级映射时，设计者站在整个组织的高度，在全局分析阶段输出的价值需求的指导下，通过系统上下文呈现利益相关者、目标系统与伴生系统之间的关系。系统上下文实际上确定了解空间的边界，除了系统边界与外部环境之间必要的集成，整个开发团队都工作在系统上下文的边界之内。一旦确定了系统上下文，就可以根据全局分析阶段输出的业务需求执行业务级映射。根据语义相关性和功能相关性对业务服务表达出来的业务知识进行归类与归纳，即可识别出边界相对合理的限界上下文。限界上下文的内部架构遵循菱形对称架构模式，充分体现它作为自治的架构单元、领域模型的知识语境，提供独立完整的业务能力；限界上下文之间则通过不同的上下文映射模式表达上游和下游之间的协作方式，规范服务契约。系统级映射建立在限界上下文之上，在全局分析阶段划分的子领域的指导下，在系统上下文的边界内部建立系统分层架构。该分层架构将属于核心子领域的限界上下文映射为业务价值层，将支撑子领域和通用子领域的限界上下文映射为基础层，并从前端用户体验的角度考虑引入边缘层，为前端提供一个统一的网关入口，并通过聚合服务的方式响应前端发来的客户端请求。架构映射阶段的里程碑目标是完成从问题空间到解空间的架构映射，通过组织级映射、业务级映射和系统级映射获得遵循领域驱动架构风格的架构映射战略设计方案（参见附录D）。架构映射阶段就是目标系统的架构战略设计。解决方案的获得建立在全局分析结果的基础之上，不同层次的映射方法引入了不同的领域驱动设计元模型，建立的领域驱动架构风格发挥了这些设计元模型的价值，保证了目标系统架构的一致性，以限界上下文为核心的业务级架构与系统级架构也成了响应业务变化的关键。参与架构映射阶段的角色包括业务分析师、产品经理、用户体验设计师、项目经理、架构师、技术负责人、开发人员。其中，业务分析师和产品经理共同扮演领域专家的角色。由于架构映射阶段属于解空间的范畴，邀请客户参与本阶段的战略设计活动，可能会适得其反。若有必要，在执行组织级映射获得系统上下文的过程中，可以咨询和参考客户的意见。在本阶段，架构师（尤其是业务架构师与应用架构师）应成为关键的引导者和推动者。3．领域建模阶段领域建模阶段是对问题空间战术层次的求解过程，它的目标是建立领域模型。领域建模必须在领域驱动架构风格的约束下，在限界上下文的边界内进行。这样一方面用分而治之的思想降低了领域建模的难度，另一方面也体现了领域建模依据的统一语言存在限定的语境，这也是模型驱动设计区别于其他建模过程的根本特征。根据领域模型表现特征的不同，领域建模可分为领域分析建模、领域设计建模和领域实现建模，对应于本阶段的3个主要过程工作流。整个领域建模阶段与主要工作流的关系如图3-4所示。领域建模是一个统一而连续的过程。执行领域分析建模时，以领域专家为主导，整个领域特性团队共同针对限界上下文对应的领域开展分析建模，即在统一语言的指导下对业务服务进行提炼与抽象，获得的领域概念形成领域分析模型；执行领域设计建模时，以开发团队为主导，围绕每个完整的业务服务开展设计工作，获得领域设计模型；领域实现建模仍然由开发团队主导，在拆分业务服务为任务的基础上开展测试驱动开发，编写出领域相关的产品代码和单元测试代码，形成领域实现模型。领域分析模型、领域设计模型和领域实现模型共同组成了领域模型。在执行主要的过程工作流时，还需要注意领域分析模型、领域设计模型和领域实现模型之间的同步，保证领域模型的统一。推动领域建模完成从问题空间到解空间战术求解的核心驱动力是“领域”，在领域驱动设计统一过程中，就是通过业务服务表达领域知识，成为领域分析建模、领域设计建模和领域分析建模的驱动力。领域建模阶段的里程碑目标是完成从问题空间到解空间的模型构建，通过领域分析建模、领域设计建模和领域实现建模逐步获得领域模型。领域模型包括如下内容。q领域分析模型：业务服务规约和领域模型概念图。q领域设计模型：以聚合为核心的静态设计类图和由角色构造型组成的动态序列图与序列图脚本。q领域实现模型：实现业务功能的产品代码和验证业务功能的测试代码。参与领域建模阶段的角色主要为领域特性团队业务分析师、开发人员和测试人员，其中业务分析师负责细化业务服务，测试人员为业务服务编写验收标准，开发人员进行服务驱动设计和测试驱动开发，共同完成领域建模。3.2.3　统一过程的静态结构领域驱动设计统一过程通过纵轴展现了工作流（work flow），包括过程工作流与支撑工作流。其中，在执行过程工作流时，还需要应用领域驱动设计元模型中的模式（pattern）或丰富到领域驱动设计体系中的方法（method）。1．过程工作流在讲解领域驱动设计统一过程的各个阶段时，我已阐述了这些阶段与各个过程工作流之间的关系，图3-1也通过工作流图示的面积大小体现了这种关系。这一对应关系主要体现了各个阶段执行活动的主次之分，过程工作流的执行效果会直接影响阶段的里程碑与产出物。统一过程的所有过程工作流都运用了领域驱动设计的设计元模型。正是通过这种方式将相对零散的设计元模型糅合到一个完整的设计过程中，为开发团队运用领域驱动设计提供过程指导。为了更好地使领域驱动设计落地，我在沿用设计元模型的基础上，丰富了领域驱动设计体系，增加了一些新的方法，这些方法也可以认为是设计元模型的一部分。过程工作流与其运用的设计元模型之间的关系如表3-1所示。表3-1　过程工作流与设计元模型过程工作流模式方法价值需求分析统一语言商业模式画布业务需求分析统一语言、核心子领域、通用子领域、支撑子领域业务流程图、服务蓝图、业务服务图、事件风暴组织级映射系统上下文系统上下文图、业务序列图业务级映射限界上下文、上下文映射、菱形对称架构V型映射过程、事件风暴、服务序列图、康威定律、领域特性团队系统级映射核心子领域、通用子领域、支撑子领域、系统分层架构康威定律领域分析建模统一语言、限界上下文、模型驱动设计快速建模法、事件风暴领域设计建模统一语言、模型驱动设计、实体、值对象、聚合、领域服务、领域事件、资源库、工厂、事件溯源角色构造型、服务驱动设计领域实现建模统一语言、模型驱动设计测试驱动开发、简单设计、测试金字塔 无论模式还是方法，都有知识零散之虞，它们就像一颗颗晶莹剔透的珍珠，在实践落地时常常会有遗珠之憾，因此需要用领域驱动设计统一过程这条线把它们串联起来，打造成一件完整的珠宝首饰，如此才能发出整体的耀眼光芒。2．支撑工作流虽说领域驱动设计是以“领域”为核心关注点的软件构建过程，但它仍然属于软件构建的技术范畴；而我们在软件构建工作中面对的太多问题，实际属于管理学的范畴。《人件》认为：“开发的本质迥异于生产；然而，开发管理者的思想却通常被生产环境衍生而来的管理哲学所左右。”[13]同理，当我们改变了软件构建的过程时，如果还在沿用过去那一套管理软件构建的方法，就会出现“水土不服”的现象。因此，领域驱动设计统一过程需要对项目管理流程、需求管理体系和团队管理制度做出相应的调整，这些共同组成了统一过程的支撑工作流。关于项目管理，Eric Evans早在十余年前就提到了敏捷开发过程与领域驱动设计之间的关系，他提出了两个开发实践[8]3：q迭代开发；q开发人员与领域专家具有密切的关系。领域驱动设计统一过程并未对项目管理流程做出硬性的规定，然而迭代开发因为其增量开发、小步前行、快速反馈、响应变化等优势，能够非常好地与领域驱动设计相结合，可考虑将其引入领域建模阶段，形成分析、设计和实现的迭代建模与开发流程。全局分析阶段与架构映射阶段也可采用迭代模式，但它们在管理流程上更像RUP的先启阶段。短暂快速的先启阶段与迭代建模的增量开发相结合，形成一种“最小计划式设计”。它是软件开发过程的中庸之道，既避免了瀑布型的计划式设计因为庞大的问题空间形成分析瘫痪（analysisparalysis），又不至于走向无设计的另一个极端。领域驱动设计的成败很大程度上取决于需求的质量。全局分析阶段的主要目标就是对问题空间进行价值需求分析与业务需求分析；在领域建模阶段，也需要领域特性团队的业务分析师针对全局分析获得的业务服务进行深入分析。这些都是领域驱动设计统一过程对需求管理流程的要求。与需求管理流程不同，领域驱动设计统一过程并没有强制约定需求分析的方法，团队可以根据自身能力和方法的要求，选择用例需求分析方法，也可以选择协作性更强的用户故事地图或者事件风暴，甚至将多种需求分析方法与实践结合起来，只要能获得更有价值的业务需求。当然，为了让参与者能够在需求分析与管理过程中达成共识，也需要就需求术语定义“统一语言”。表3-2列出了统一过程使用的技术术语与主流需求分析方法使用的技术术语之间的对应关系。表3-2　需求分析的统一语言领域驱动设计统一过程业务与系统建模精益需求用户故事地图事件风暴业务流程业务序列图用户体验地图叙事主线事件流业务场景业务用例史诗故事无关键事件与泳道业务服务系统用例特性活动决策命令业务任务用例执行步骤用户故事任务决策命令 领域驱动设计统一过程使用业务流程、业务场景、业务服务和业务任务4个层次的技术术语来体现不同层级的业务需求。领域驱动设计对团队管理也提出了要求：“团队共同应用领域驱动设计方法，并且将领域模型作为项目沟通的核心。”[8]6这一要求的目的是让团队成员更好地沟通与交流，并在团队内部形成一种公共语言，在开发节奏上保持与建模过程的步调一致。为了促进团队的充分交流，应为提供业务能力的限界上下文建立领域特性团队，为具有内聚功能的模块建立组件团队，针对客户端调用者尤其是前端UI建立前端组件团队，这种团队组建方式也符合康威定律的要求。未完待续

只凭经验，我们得经过遥遥辽远的汗漫之游，才能得到便利直捷之径。——洛节·爱铿，转引自托马斯·哈代的《德伯家的苔丝》距离领域驱动设计的提出已有十余年，开发人员面对的软件开发模式、开发技术和IT规模都有了天翻地覆的变化。即使领域驱动设计作为一种设计思维方式与软件设计过程，并未涉及具体的开发技术，但技术的发展仍然会对它产生影响，就连Eric Evans自己也认为：“如果在推行领域驱动设计时继续照本宣科地使用《领域驱动设计》一书，这就不太光彩了！”[1]上次谈到针对领域驱动设计现存的这4个不足，我对领域驱动设计体系进行了精简与丰富。精简，意味着做减法，就是要剔除设计元模型中不太重要的模式，凸显核心模式的重要性，并对领域驱动设计过程进行固化，提供简单有效的实践方法。软件构建的过程就是不断对问题空间求解获得解决方案，进而组成完整的解空间的过程。在这个过程中，若要构建出优良的软件系统，就需要不断控制软件的复杂度。因此，我对领域驱动设计的完善，就是在问题空间与解空间背景下，定义能够控制软件复杂度的领域驱动设计过程，并将该过程执行的工作流限定在领域关注点的边界之内，避免该过程的扩大化。我将这一过程称为领域驱动设计统一过程（domain-driven design unified process，DDDUP）。3.2.1　统一过程的二维模型领域驱动设计统一过程参考了统一过程（rationalunified process，RUP）的二维开发模型。整个过程的二维模型如图3-1所示，横轴代表推动领域驱动设计在构建过程中的时间，体现了过程的动态结构，构成元素主要为3个阶段（phase），每个阶段可以由多个迭代构成；纵轴表现了领域驱动设计在各个阶段中执行的活动，体现了过程的静态结构，构成元素包括工作流（workflow）和元模型（meta model）。不同于RUP等项目管理过程，领域驱动设计统一过程并没有也不需要覆盖完整的软件构建生命周期，例如软件的部署与发布就不在该统一过程的考虑范围内。结合领域驱动设计对问题空间和解空间的阶段划分、对战略设计和战术设计的层次划分，整个统一过程分为3个连续的阶段：q全局分析阶段；q架构映射阶段；q领域建模阶段。每个阶段都规定了自己的里程碑和产出物。里程碑作为阶段目标，可以作为该阶段结束的标志，避免团队无休止地投入人力物力到该阶段的工作流中；每个阶段都必须输出产出物，这些产出物无论形式如何，都是领域知识的一部分，并作为输入，成为执行下一阶段工作流的重要参考，甚至可以指导下一个阶段工作流的执行。根据情况，团队可以对每个阶段的产出物进行评审。每个团队可以设定验收规则，甚至做出严格规定，只有本阶段产出物通过了评审，才可以进入下一个阶段。统一过程的每个阶段要执行的活动主要通过工作流来表现，一个工作流就是一个具有可观察结果的活动序列。整个统一过程的工作流分为过程工作流（process work flow）与支撑工作流（supporting work flow）。每个工作流都可能贯穿统一过程的所有阶段，只不过因为阶段目标与工作流活动的不同，工作流在不同阶段所占的比重各不相同，意味着在不同阶段花费的人力成本与时间成本的不同。图3-1中工作流图例的面积直观地体现了这种成本的差异。例如，价值需求分析工作流主要用于确定系统的利益相关者、系统愿景和系统范围，这些活动与全局分析阶段需要达成的里程碑相吻合，但这并不意味着在项目进入架构映射阶段时就不需要执行该工作。软件系统就像一座不断扩张的城市，通过价值需求分析获得的利益相关者、系统愿景和系统范围也会随着软件系统问题空间的变化而发生调整，其他工作流同样如此。过程工作流构成了领域驱动设计统一过程的主要活动，它融合了领域驱动设计元模型，为工作流提供设计原则和模式的指导。这也使得整个统一过程保留了领域驱动设计的特征，遵循了“以领域为驱动力”的核心原则。支撑工作流严格说来不属于领域驱动设计的范围，但对它们的选择却会在整个统一过程中不断地影响着实施领域驱动设计的效果。领域驱动设计不能与它们强行绑定，毕竟不同企业、不同团队的文化基因和管理机制存在差异，但需要选择与领域驱动设计统一过程具有高匹配度的支撑工作流。3.2.2　统一过程的动态结构领域驱动设计统一过程的动态结构通过3个阶段，从问题空间到解空间完整而准确地展现了运用领域驱动设计构建目标系统的过程。这里所谓的“目标系统”是一个抽象的概念，取决于领域驱动设计统一过程的运用范围，既可大至整个组织，将该组织的所有IT系统都囊括在这一统一过程之下（问题空间的范围也将由此扩大至整个组织），也可小至一个已有系统的新开发功能模块，将其独立出来，严格遵循该统一过程，运用领域驱动设计完成其构建。目标系统的大小直接决定了问题空间的大小，自然也就决定了它所映射的解空间的大小。1．全局分析阶段全局分析（big picture analysis）阶段的目标是探索与分析问题空间。该阶段主要通过对目标系统执行价值需求分析与业务需求分析这两个工作流，完全抛开对解决方案的思考与选择，仅仅从需求分析的角度以递进方式开展对问题空间的深入剖析。整个全局分析过程如图3-2所示。从价值需求开始，识别目标系统的利益相关者，明确系统愿景，识别系统范围。只有明确了利益相关者，才能就不同利益相关者的项目目标达成共识，以明确组织对目标系统树立的愿景，确保构建的目标系统能够对准组织的战略目标，避免软件投资方向的偏离。通过了解目标系统的当前状态和预期的未来状态，可以确定目标系统的范围，从而界定问题空间的边界，为进一步探索目标系统的解决方案提供战略指导。价值需求分析的成果看似虚无缥缈，似乎都是宏观层次言不及义的大话、套话，实则描绘了目标系统的蓝图，避免开发团队只见树木不见森林，缺乏对系统的整体把控。同时，它还指明了目标系统的方向，为我们确定和排列业务需求优先级提供了参考，为解空间进行技术选型和技术决策提供了依据，做出恰如其分的设计。在价值需求的指导和约束下，根据用户发起的服务请求，逐一梳理出提供业务价值的动态业务流程，体现了多个角色在不同阶段进行协作的执行序列。每个业务流程都具有时间属性，通过划定里程碑时间节点，即可在业务目标的指导下将业务流程划分为不同时间阶段的多个业务场景。业务场景由多个角色共同参与，每个角色在该场景下与目标系统的一次功能交互，都是为了满足该角色希望获得的服务价值，由此即可获得业务服务。在对业务需求进行深入分析后，可以结合价值需求分析的结果，将那些对准系统愿景的业务需求放到核心子领域，将提供支撑作用的业务需求放到支撑子领域，将提供公共功能的业务需求放到通用子领域，由此就可以从价值角度完成对问题空间的分解。全局分析阶段的里程碑目标是探索和固定目标系统的问题空间，通过分析价值需求与业务需求，获得以业务服务为业务需求单元的全局分析规格说明书（参见附录D）。参与全局分析阶段的角色包括客户或客户代表、业务分析师、产品经理、用户体验设计师、架构师或技术负责人、测试负责人。其中，客户、业务分析师、产品经理共同扮演领域专家的角色，并在本阶段作为关键的引导者和推动者。

梳理之后的领域设计类图非常规范。除了合成关系，存在OO聚合关系的实体都分到不同的聚合中，更不用说完全独立的Backlist实体。如果多个聚合边界的实体依赖了相同的值对象，可以定义多个相同的值对象，然后将它们放到各自的聚合边界内。分解关系薄弱处确定的聚合边界如图20-55所示。考虑聚合设计原则，由于Learning聚合中的Course实体具有独立性，因此需要对图20-55稍做调整，将Course实体分离出来，定义为单独的聚合。除此之外，其余聚合边界都是合理的，不需再做调整。最终，确定了聚合边界的领域设计类图如图20-56所示。由此得到的聚合包括：qTraining聚合；qCourse聚合；qLearning聚合；qTicket聚合；qTicketHistory聚合；qFilter聚合；qValidDate聚合；qValidDateAction聚合；qCancellingAction聚合；qCandidate聚合；qAttendance聚合；qBlacklist聚合。即使在领域设计模型中，我们也无须为领域模型对象定义字段。每个聚合内的实体或值对象到底需要定义哪些字段，可以结合业务服务，通过测试驱动开发逐步驱动出来。领域设计类图最重要的要素是聚合。一旦确定了聚合，实际上也就确定了管理聚合生命周期的资源库。至于需要哪些领域服务和其他角色构造型，可以交由服务驱动设计来识别。（2）服务驱动设计服务驱动设计的起点是业务服务。以提名候选人业务服务为例，将业务服务规约的基本流程转换为由动词短语组成的任务，然后通过向上归纳和向下分解获得由组合任务与原子任务组成的任务树：q提名候选人（业务服务）♦   确定候选人是否已经参加过该课程○   获取该培训对应的课程○   确定课程学习记录是否有该候选人♦   如果未参加，则提名候选人○   获得培训票○   提名○   保存票的状态♦   发送提名通知○   获取通知邮件模板○   组装提名通知内容○   发送通知结合任务分解与角色构造型，它的序列图脚本如下： NominationAppService.nominate(nominationRequest) {   LearningService.beLearned(candidateId, trainingId) {      TrainingRepository.trainingOf(trainingId);      LearningRepository.isExist(candidateId, courseId);   }   TicketService.nominate(ticketId, candidate) {      TicketRepository.ticketOf(ticketId);      Ticket.nominate(candidate);      TicketRepository.update(ticket);   }   NotificationService.notifyNominee(ticket, nominee) {      MailTemplateRepository.templateOf(templateType);      MailTemplate.compose(ticket, nominee);      NotificationClient.notify(notificationRequest);   }} 该序列图脚本对应的序列图如图20-57所示。图20-57中的NominationAppService应用服务承担了多个领域服务之间的协作职责，且需要根据beAttend()方法的返回结果决定提名的执行流程。这实际上属于领域逻辑的一部分，故而应该在NominationAppService应用服务内部引入一个领域服务来封装这些业务逻辑。新增的领域服务为NominationService，修改后的序列图如图20-58所示。图20-58中的MailTemplate是一个聚合，存储了不同类型操作需要通知的邮件模板。在前面的领域分析建模与领域设计建模时，未能发现该聚合。这也印证了领域建模很难一蹴而就，需要不断地迭代更新和演进。

遵循系统分层架构与菱形对称架构对代码模型的约束和规定，EAS系统的代码模型如图20-50所示。所有限界上下文都采用了菱形对称架构规定的标准代码模型，只是根据具体情况作了少量调整。各个限界上下文在系统分层架构所处的层次，也通过包的命名空间清晰地呈现出来了。20.3.4EAS的领域建模在确定了EAS系统的限界上下文与系统上下文，并通过菱形对称架构和系统分层架构设计出EAS的整体架构后，接下来就进入了战术层面的领域建模阶段。考虑到篇幅原因，我仅选择了业务逻辑相对复杂的培训上下文，运用快速建模法对其进行领域分析建模，获得领域分析模型后，采用庖丁解牛的过程设计聚合，然后相继开展服务驱动设计与测试驱动开发获得最终的领域模型。1．领域分析建模领域分析建模阶段的关键是识别领域概念，为限界上下文建立领域分析模型。参考过程模型推荐使用快速建模法进行领域分析建模，它的基础是业务服务规约。以“提名候选人”业务服务为例，它的业务服务规约如下。 服务编号：EAS-0202服务名：提名候选人服务描述：　　作为一名协调者　　我想要提名候选人参加培训　　以便部门的员工得到技能培训的机会触发事件：　　协调者选定候选人后，点击“报名”按钮基本流程：1．确定候选人是否已经参加过该课程2．对培训票提名候选人3．邮件通知获得提名的候选人替换流程：1a．候选人参加过该培训要学习的课程，提示员工已经学习过该课程2a．提名操作失败，提示失败原因验收标准：1．被提名人属于候选名单中的员工2．提名的票状态必须为Available3．提名后的票状态为WaitForConfirm4．候选人获得培训票

20.3.3EAS的架构映射通过对EAS展开全局分析，我们已经获得了EAS系统的价值需求和业务需求。接下来，我将延续全局分析阶段输出的这些成果，开展架构映射，获得遵循领域驱动架构风格的架构映射战略设计方案。1．映射系统上下文全局分析阶段确定了EAS的利益相关者。通过对目标系统的分析，可以得出参与系统上下文的用户包括：集团决策者、市场部、人力资源部、项目管理部、子公司、服务中心、财务、员工。整个目标系统就是EAS系统。在确定系统范围时，系统的当前状态告诉我们：集团已有OA系统提供部门之间的流程协作与消息通知，它是EAS系统的伴生系统。系统的当前状态虽然还告知软件学院和招聘网站的简历会作为集团的人才储备库，却并未确认EAS系统是否需要和软件学院与招聘网站集成。通过招聘流程服务蓝图可以确知，这些简历信息需要招聘专员手工录入EAS系统，因此，EAS系统的伴生系统并不包含软件学院和招聘网站。客户合作流程服务蓝图中的内部支持者包含了薪资管理系统，调用它提供的服务接口可以获得员工薪资，以便财务进行财务核算，这说明薪资管理系统也是EAS系统的伴生系统。EAS系统的系统上下文如图20-27所示。确定了系统上下文，就确定了EAS系统的解空间，同时也确定了位于解空间之外的伴生系统。2．映射限界上下文在全局分析阶段，EAS系统的问题空间被分解为业务场景下的各个业务服务。遵循业务维度的V型映射过程，需要针对这些业务服务进行归类和归纳，获得各个业务主体，再根据亲密度和限界上下文的特征对业务主体的边界进行调整，并运用验证原则验证业务边界的合理性。之后，根据管理维度的工作边界、技术维度的应用边界逐步对限界上下文做进一步的调整。（1）归类与归纳V型映射过程从识别业务服务的语义相关性与功能相关性开始。语义相关性主要针对业务服务名的名词。例如，在客户活动业务流程中，诸如“创建合同”“添加附加合同”“指定合同承担者”等业务服务都包含“合同”一词，可归类到同一个业务主体，如图20-28所示。功能相关性则从业务服务的业务目标进行归类，如图20-29中的业务服务都与市场管理的业务目标有关，可归类到同一个业务主体。通过语义相关性和功能相关性对业务服务进行归类后，可以进一步针对它们表达的概念建立抽象，寻找共同特征完成对类别的归纳。例如，图20-29中的业务服务涵盖了市场需求、需求订单、客户需求等领域概念，它们都可以提炼为一个更高的抽象层次——市场。这也是图中业务主体名称的由来。从中也可发现，虽然归类与归纳属于V型映射过程的两个环节，但这两个环节并没有清晰的界限，在进行归类时，可以同时进行归纳。无论是寻找领域概念的共同特征，还是识别领域行为的业务目标，都需要一种抽象能力。在进行抽象时，可能出现“向左走还是向右走”的困惑，因为抽象层次的不同，抽象的方向或依据亦有所不同。这时就需要做出设计上的决策。例如对识别出来的“员工”与“储备人才”领域概念，可以抽象出“人才”的共同特征，得到图20-30所示的人才业务主体。从共同的业务目标考虑，储备人才又是服务于招聘和面试的，似乎归入招聘业务主体才是合理的选择，如图20-31所示。还有第三种选择，就是将储备人才单独抽离出来，形成自己的储备人才业务主体，如图20-32所示。该如何抉择呢？我认为须得思考识别业务主体的目的。业务主体是架构映射过程的中间产物，并非最终的设计目标。业务主体是对业务服务的分类，为限界上下文的识别提供了参考。因此，选择人才主体，还是招聘主体，或者单独的储备人才主体，都需要从限界上下文与领域建模的角度去思考。如果暂时分辨不清楚，可以先做出一个初步选择，待所有的业务主体都归纳出来之后，在梳理业务主体的边界时再决定。识别业务主体不是求平衡，更不是为了让设计的模型更加好看。业务主体是根据业务相关性进行归类和归纳的，必然会出现各个业务主体包含的业务服务数量不均等的情形。例如，与项目管理有关的业务主体，包含的业务服务数量非常不均匀。项目业务主体的业务服务数量最多，如图20-33所示。

不同参与者的取消流程虽然不同，但在业务服务图中，实际要执行的业务服务都是“取消票”。培训专员和系统都可以处理票，区别在于一个是人工，一个是自动，后者的触发条件与触发时机相对比较复杂。对这些领域逻辑的描述可以在领域建模阶段通过业务服务规约进一步细化。获得提名并参加培训的部门员工称为“学员”，如此可以更好地体现其身份。培训的业务服务图如图20-25所示。培训业务规则规定，如果学员没有提交培训请假申请或请假申请未通过，却未曾参加培训且未签到，会被视为缺勤。在培训流程的服务蓝图中，根据业务规则，缺勤学员会被放入黑名单，然而这一活动并未在业务服务图中体现出来。这是因为学员被加入黑名单实际是“确认缺勤名单”业务服务产生的一个结果，并非一个独立的业务服务。分析EAS的业务需求时，从业务流程到业务场景，再从业务场景到业务服务，应该是一个水到渠成的过程。在这个过程中，最好能引入“现场客户”（极限编程中的一个实践），共同探索业务需求，梳理出问题空间的业务需求全貌。为了避免分析瘫痪，在全局分析阶段，业务需求分析在获得业务服务这个粒度时就可以结束，进入架构映射阶段。然而，对业务服务做进一步细化仍然属于需求分析的过程，与开发团队开展架构映射属于两个并行不悖的工作，细化获得的业务服务规约也将作为领域建模阶段的重要输入。因此，需求分析人员也可在全局分析阶段针对核心子领域的业务服务编写业务服务规约。组成EAS全局分析规格说明书的业务需求如下所示。 1 业务流程包括EAS的核心流程与各个具体的业务流程，可通过业务流程图或服务蓝图呈现。前文已述，现略去。2 业务场景和业务服务针对每个具体的业务流程，按照业务目标进行划分，获得每个具体的业务场景，并按照业务服务的判断标准识别业务服务，通过业务服务图呈现出来。前文已述，现略去。3 业务服务规约对每个业务服务进行细化，获得业务服务规约。3.1 客户合作3.1.1 市场需求管理（1）创建市场需求服务编号：EAS-0001服务描述：　　作为市场人员　　我想要创建一条市场需求　　以便随时了解市场需求的状态触发事件：　　市场人员输入市场需求，点击“创建”按钮基本流程：1．验证输入的市场需求，包括需求名称、描述、客户、备注2．按照规则生成市场需求编号3．验证市场需求名称是否已经存在4．创建市场需求替代流程：1a．当市场需求名称在系统中已存在，给出提示信息4a．若市场需求创建失败，给出失败原因验收标准：1．市场需求的名称只能为中文、英文或数字，长度不超过50个字符，不能重复　　　2．输入的市场需求中，必须包含市场需求名称、描述和客户，客户为系统已有客户，备注为可选3．市场需求编号规则为：EAS-客户ID-自增长数，市场需求编号不允许重复4．市场需求被成功创建3.1.2 合同管理（1）归档合同服务编号：EAS-0011服务描述：作为市场人员我想要对合同进行归档以便保存合同副本，避免合作纠纷触发事件：市场人员选择合同文档，点击“上传”按钮基本流程：1．验证文档类型的有效性2．上传合同文档3．保存合同文档4．更新合同信息替代流程：1a．若上传的文档类型并非PDF文档，给出提示信息2a．若上传的文档超出系统规定的文件大小，给出提示信息3b．若上传合同文档时，文件传输失败，给出失败原因4a．更新合同信息失败，给出失败原因验收标准：1．归档的合同文档只能为PDF文件，可仅验证文档文件的扩展名　2．服务器归档主文件夹为contract/archive，归档保存时，需验证该文件夹是否存在，如果不存在，需要创建该文件夹3．为合同归档文件创建子文件夹，子文件夹名为合同ID4．若归档时，在指定文件夹中已有同名文件存在，则为“另存为”操作，当前文件名增加“（1）”作为后缀5．合同的归档文件属性添加归档文件夹路径 ……3.3 项目管理……3.3.3 项目成员管理（1）添加项目成员服务编号：EAS-0105服务描述：作为项目管理者我想要添加项目成员以便管理项目成员触发事件：项目管理者选定员工和项目角色，点击“添加”按钮基本流程：1．验证员工是否工作在其他项目2．将员工加入项目团队，成为项目成员3．修改员工的工作状态4．发送邮件通知员工5．为员工简历追加项目经验替代流程：1a．选定员工如果已经加入其他项目，给出提示2a．添加员工失败，给出错误信息5a．若员工已具备该项目经验，则忽略验收标准：1．选定的员工应为“on bench”状态2．员工被加入项目团队后，状态应变更为“项目中”3．员工简历中的项目经验信息不能重复4．员工简历中的项目经验包括：项目名称、项目描述、担任的项目角色 3．划分子领域全局分析阶段对问题空间的识别也是对客户痛点与系统价值的识别。之所以要开发目标系统，就是要解决客户的痛点，并为客户提供具有业务价值的功能。在识别痛点与价值的过程中，需要始终从业务期望与愿景出发，与不同的利益相关者进行交流，如此才能达成对问题空间的共同理解。对EAS而言，集团决策层要解决“供需平衡”这一根本的痛点，就需要及时了解当前有哪些客户需求、目前又有哪些人力资源可用，这就需要打破市场部、人力资源部和项目管理部之间的信息壁垒，对市场需求、人力资源、项目的信息进行统计，提供直观的分析结果，进而根据这些分析结果为管理决策提供支持。我们需要就这几个主要部门了解部门员工的痛点和对价值的诉求。市场部员工（市场人员）面临的痛点是无法通过人工管理的方式高效维护与客户的良好合作关系，故而其价值诉求就是提高客户关系管理的效率，使得能够快速地响应客户需求，敏锐地发现潜在客户，掌握客户动态，进而针对潜在客户开展针对性的市场活动。市场部员工希望能够建立快速通道，及时明确项目承担者（即子公司）是否能够满足客户需求，降低市场成本。市场部门还需要准确把握需求的进展情况，跟进合同签署流程，提高客户满意度。人力资源部员工（招聘专员）的痛点是需要制订合理的招聘计划，使得聘用的人才满足日益增长的客户需求，又不至于产生大量的人力资源闲置，导致集团的人力成本浪费。站在精细管理的角度考虑，从潜在的市场需求开始，招聘专员就需要与市场部、子公司共同确定招聘计划。制订计划的依据在于潜在的人力资源需求，包括对技能水平的要求、语言能力的要求，同时也需要考虑目前子公司的员工利用率，并参考历史的供需关系来做出尽可能准确的预测。员工的技能是一种重要的输出资源，人力资源部需要针对客户对人员能力的要求制订培训计划，在企业内部组织员工培训，提升员工技能，如此就能以最小成本输出最大的人力资源价值。因此，人力资源部的价值诉求就是让招聘与培训具有计划前瞻性与精确性，更好地在客户需求与人力资源之间维护供需的平衡。项目管理部负责企业的“生产管理”，对项目以及项目成员的管理直接关系到客户满意度。在没有EAS之前，市场部的苦恼是不了解已签合同的项目执行情况，即使市场部主动与项目管理部进行沟通，项目管理部也无法提供精确的项目信息，更谈不上及时了解项目的进度情况。因此，市场部的价值诉求是了解项目进度以促进与客户的良好合作关系，而项目管理部的价值诉求是及时了解项目过程执行情况，发现不健康的项目，通过项目管理手段规避延迟交付甚至交付失败的风险，提高项目的成功率。识别了痛点与价值，即可借此划分子领域细分问题空间。并通过识别核心子领域、通用子领域和支撑子领域来区分核心问题和次要问题。由于EAS是为软件集团应用信息化服务的，我们可以在识别出痛点与价值的基础之上，从业务职能与业务概念相结合的功能分类策略确定整个问题空间的子领域，由此获得的核心子领域如下：q决策分析；q市场需求管理；q客户关系管理；q员工管理；q人才招聘；q技能培训；q项目进度管理。除了这些核心子领域，诸如组织结构、认证和授权都属于通用的子领域，每个核心子领域都需要调用这些子领域提供的功能。注意，虽然通用子领域提供的功能不是系统业务的核心，但缺少这些功能，业务却无法流转。之所以没有将这些功能识别为核心子领域，是因为有对问题空间的理解分析。例如，组织结构管理是保证业务流程运转以及员工管理的关键，用户的认证与授权则是为了保证系统的访问安全，都没有直接对“供需平衡”这一业务愿景提供业务价值，因而不是利益相关人亟待解决的痛点。在分辨系统的利益相关者时，服务中心作为参与EAS的业务部门，主要为项目及项目人员提供工位和硬件资源，要解决的是资源分配的问题。这一功能的引入固然可以帮助企业降低运营成本，却与价值需求中的系统愿景没有直接关系，因此可以将该子领域作为一种支撑子领域。除此之外，消息通知和文件上传下载也支持了大部分核心领域的执行活动，都属于独立的支撑子领域。EAS的子领域映射图如图20-26所示。划分子领域分解了问题空间，使得团队能对EAS达成共同理解，识别出来的各个子领域也将作为解空间形成的架构方案的参考，尤其是系统分层架构的参考。子领域也属于全局分析规格说明书的一部分。

只凭经验，我们得经过遥遥辽远的汗漫之游，才能得到便利直捷之径。——洛节·爱铿，转引自托马斯·哈代的《德伯家的苔丝》距离领域驱动设计的提出已有十余年，开发人员面对的软件开发模式、开发技术和IT规模都有了天翻地覆的变化。即使领域驱动设计作为一种设计思维方式与软件设计过程，并未涉及具体的开发技术，但技术的发展仍然会对它产生影响，就连Eric Evans自己也认为：“如果在推行领域驱动设计时继续照本宣科地使用《领域驱动设计》一书，这就不太光彩了！”[①]领域驱动设计具有一定的开放性，只要遵循“以领域为驱动力”的核心原则，就可以在软件构建过程中使用不限于领域驱动设计提出的方法，以控制软件复杂度。事实上，在领域驱动设计社区的努力下，如今的领域驱动设计包容的实践方法与模型已经超越了Eric Evans最初提出的领域驱动设计范畴。这是一套可以自我成长自我完善的过程体系，只要软件仍然以满足用户的业务需求为己任，领域驱动设计就不会脱离它成长的土壤。既然看到了领域驱动设计的开放性，只要不违背它的核心原则，我们自然可以按照对它的理解，结合自身在项目中的实践来扩展整套方法论。社区对领域驱动设计的补充更多地体现在对设计元模型的不断丰富上。以“模式”作为表达方式的设计元模型是一种松散的组织方式，每个模式都有其意图与适用性，这意味着我们可以轻松地添加新的模式。目前，社区已经为这套设计元模型分别增加了诸如支撑子领域、领域事件、事件溯源、命令查询职责分离（command queryresponsibility segregation，CQRS）等模式，本书也针对上下文映射提出了发布者/订阅者模式（参见第10章），为限界上下文定义了菱形对称架构模式（参见第12章），在领域建模阶段增加了角色构造型（参见第16章）的概念，提出了服务驱动设计（参见第16章）方法。领域驱动设计的开放性还体现在适用范围的扩大。它作为一种方法论，囊括了在软件设计领域提炼出来的诸多真知灼见，并以设计原则和模式的形式将其呈现出来。这些设计原则和模式具备技术领先性和前瞻性，体现了顽强的生命力，仿佛可以预见技术发展的未来。例如：它“预见”了微服务架构，可以将限界上下文作为设计和识别微服务边界的参考模式；它“预见”了文档型的NoSQL数据库，可以使用聚合模式封装NoSQL数据库的每一项；它“预见”了中台战略，可以通过对子领域的划分提供能力中心构建的设计支持。领域驱动设计的开放性是其永葆青春的秘诀。当然，在选择为这套方法论添砖加瓦时，也不能率意而为，肆意扩大领域驱动设计的外延，仿佛它是一个筐，什么都能向里面装。本着实证主义的态度，在对现有领域驱动设计体系进行完善之前，需要充分了解它现存的不足。3.1　领域驱动设计现存的不足[②]领域驱动设计体系构建在设计元模型的基础之上，具有前所未有的开放性。然而，这种由各种模式构成的松散模型却也使得它对设计上的指导过于随意，对技能的要求过高。如果没有掌握其精髓，就难以合理地运用这些设计元模型。归根结底，领域驱动设计缺乏一个系统的统一过程作为指导。虽然领域驱动设计划分了战略设计阶段与战术设计阶段，但这两个阶段的划分仅仅是对构成元模型的模式进行类别上的划分，例如将限界上下文、上下文映射等模式划分到战略设计阶段，将聚合、实体、值对象等模式划分到战术设计阶段，却没有一个统一过程去规范这两个阶段需要执行的活动、交付的工件以及阶段里程碑，甚至没有清晰定义这两个阶段该如何衔接、它们之间执行的工作流到底是怎样的。毕竟，除了极少数精英团队，大多数开发团队都需要一个清晰的软件构建过程作为指导。领域驱动设计没能形成这样的统一过程，使得其缺乏可操作性。团队在运用领域驱动设计时，更多取决于设计者的行业知识与设计经验，使得领域驱动设计在项目上的成功存在较大的偶然性。因此，领域驱动设计缺乏规范的统一过程，是其不足之一。领域驱动设计倡导以“领域”为设计的核心驱动力，这就需要针对问题空间的业务需求进行领域知识的抽象和精炼。可是，系统的问题空间是如何识别和界定出来的？问题空间的业务需求又该如何获得，具备什么样的特征？如何定义它们的粒度和层次？如何规范和约定团队各个角色对问题空间的探索和分析？在不同阶段，业务需求的表现形式与验证标准分别是什么？针对种种问题，领域驱动设计都没有给出答案，甚至根本未曾提及这些内容！虽说可以将这些问题纳入需求管理体系，从而认为它们不属于领域驱动设计的范畴，可是，不同层次的业务需求贯穿于领域驱动设计过程的每个环节，例如识别限界上下文需要对业务需求和业务流程有着清晰的理解，建立领域模型需要的领域知识和概念也都来自于细粒度层次的业务需求，更不用说领域驱动设计本身就强调领域专家需要就领域知识与开发团队进行充分沟通。可以说，没有好的问题空间分析，就不可能获得高质量的领域架构与领域模型。因此，领域驱动设计缺乏与之匹配的需求分析方法，是其不足之二。领域驱动设计战略设计阶段的核心模式是限界上下文，指导架构设计的核心模式是分层架构，前者决定了业务架构和应用架构，后者决定了技术架构。领域驱动设计的核心诉求是让业务架构和应用架构形成绑定关系，同时降低与技术架构的耦合，使得在面对需求变化时，应用架构能够适应业务架构的调整，并隔离业务复杂度与技术复杂度，满足架构的演进性。领域驱动设计虽然给出了这些模式的特征，却失之于简单松散，不足以支撑复杂软件项目的架构需求。更何况，对于如何从问题空间映射到战略层次的解空间、问题空间的业务需求如何为限界上下文与上下文映射的识别提供参考等问题，领域驱动设计完全语焉不详。因此，领域驱动设计缺乏规范化的、具有指导意义的架构体系，是其不足之三。在战术设计阶段，领域驱动设计虽然以模型驱动设计为主线，却没有给出明确的领域建模方法。无论是否采用敏捷的迭代建模过程，整个建模过程分为分析、设计和实现这3个不同的活动都是客观存在的事实。虽然要保证领域模型的一致性，但这3个活动存在明显的存续关系，每个活动的目标、参与角色和建模知识存在本质差异，这也是客观存在的事实。领域驱动设计却没有为领域分析建模、领域设计建模和领域实现建模提供对应的方法指导，建模活动率性而为，要获得高质量的领域模型，主要凭借建模人员的经验。因此，领域驱动设计的领域建模方法缺乏固化的指导方法，是其不足之四。3.2　领域驱动设计统一过程针对领域驱动设计现存的这4个不足，我对领域驱动设计体系进行了精简与丰富。精简，意味着做减法，就是要剔除设计元模型中不太重要的模式，凸显核心模式的重要性，并对领域驱动设计过程进行固化，提供简单有效的实践方法，建立具有目的性和可操作性的构建过程；丰富，意味着做加法，就是突破领域驱动设计的范畴，扩大领域驱动设计的外延，引入更多与之相关的方法与模式来丰富它，弥补其自身的不足。软件构建的过程就是不断对问题空间求解获得解决方案，进而组成完整的解空间的过程。在这个过程中，若要构建出优良的软件系统，就需要不断控制软件的复杂度。因此，我对领域驱动设计的完善，就是在问题空间与解空间背景下，定义能够控制软件复杂度的领域驱动设计过程，并将该过程执行的工作流限定在领域关注点的边界之内，避免该过程的扩大化。我将这一过程称为领域驱动设计统一过程（domain-driven design unified process，DDDUP）。未完待续[①]   来自 Eric Evans 在2017年的Explore DDD 大会上所作的开幕式主题演讲。[②]   这里分析的不足，主要针对Eric Evans的著作《领域驱动设计》中的内容，社区针对这些不足也提出了各自的解决方案或模式。本文摘录于张逸老师新书《解构领域驱动设计》。

子领域的边界明确了问题空间中领域的优先级，限界上下文的边界则确保了领域建模的最大自由度。这也是战略设计在分治上起到的效用。当我们在战略层次从问题空间映射到解空间时，子领域也将映射到限界上下文，即可根据子领域的类型为限界上下文选择不同的建模方式。例如为处于核心子领域的限界上下文选择领域模型（domainmodel）模式，为处于支撑子领域（supporting subdomain）的限界上下文选择事务脚本（transactionscript）模式，这样就可以灵活地平衡开发成本与开发质量。战术设计阶段需要在限界上下文内部开展领域建模，前提是你为限界上下文选择了领域模型模式。在限界上下文内部，需要通过分层架构将领域独立出来，在排除技术实现的干扰下，通过与领域专家的协作在统一语言的指导下逐步获得领域模型。战术设计阶段最重要的设计元模型是聚合模式。虽然聚合是实体和值对象的概念边界，然而在获得了清晰表达领域知识的领域模型后，我们可以将聚合视为表达领域逻辑的最小设计单元。如果领域行为是无状态的，或者需要多个聚合的协作，又或者需要访问外部资源，则应该将它分配给领域服务。至于领域事件，则主要用于表达领域对象状态的迁移，也可以通过事件来实现聚合乃至限界上下文之间的状态通知。战略设计与战术设计并非割裂的两个阶段，而是模型驱动设计过程在不同阶段展现出来的不同视图。战略设计指导着战术设计，这就等同于设计原则指导着设计决策。EricEvans就明确指出，“战略设计原则必须把模型的重点放在捕获系统的概念核心，也就是系统的‘远景’上。”当一个业务系统的规模变得越来越庞大时，战略设计高屋建瓴地通过限界上下文规划了整个系统的架构。只要维护好限界上下文的边界，管理好限界上下文之间的协作关系，限制在该边界内开展的战术设计所要面对的就是一个复杂度得到大幅降低的小型业务系统。人们常以“只见树木，不见森林”来形容一个人不具备高瞻远瞩的战略眼光，然而，若是“只见森林，不见树木”，也未见得是一个褒扬的好词语，它往往可以形容一个人好高骛远，不愿意脚踏实地将战略方案彻底落地。无论战略的规划多么完美，到了战术设计的实际执行阶段，团队在开展对领域的深层次理解时，总会发现之前被遗漏的领域概念，并经过不断的沟通与协作，“碰撞”出对领域的新的理解。对领域概念的新发现与完善除了能帮助我们将领域模型突破到深层模型，还可能促进我们提出对战略设计的修改与调整，其中就包括对限界上下文边界的调整，从而使战略设计与战术设计保持统一。从战略设计到战术设计是一个自顶向下的设计过程，体现为设计原则对设计决策的指导；将战术设计方案反馈给战略设计，则是自底向上的演化过程，体现为对领域概念的重构引起对战略架构的重构。二者形成不断演化、螺旋上升的设计循环。领域模型驱动设计领域驱动设计是一种思维方式[8]2，而模型驱动设计则是领域驱动设计的一种设计元模型。因此，模型驱动设计必须在领域驱动设计思维方式的指导下进行，那就是面向领域的模型驱动设计，或者更加准确地将其描述为领域模型驱动设计。领域模型驱动设计通过单一的领域模型同时满足分析建模、设计建模和实现建模的需要，从而将分析、设计和编码实现糅合在一个整体阶段中，避免彼此的分离造成知识传递带来的知识流失和偏差。它树立了一种关键意识，就是开发团队在针对领域逻辑进行分析、设计和编码实现时，都在进行领域建模，产生的输出无论是文档、设计图还是代码，都是组成领域模型的一部分。EricEvans将那些参与模型驱动设计过程并进行领域建模的人员称为“亲身实践的建模者”（hands-on modeler）。模型驱动设计主要在战术阶段进行，换言之，整个领域建模的工作是在限界上下文的边界约束下进行的，统一语言的知识语境会对领域模型产生影响，至少，建模人员不用考虑在整个系统范围下领域概念是否存在冲突，是否带来歧义。由于限界上下文拥有自己的内部架构，一旦领域模型牵涉到跨限界上下文之间的协作，就需要遵循限界上下文与上下文映射的架构约束了。既然模型驱动设计是面向领域的，就必须明确以下两个关键原则。以领域为建模驱动力：在建模过程中，针对领域知识提炼抽象的领域模型，并不断针对领域模型进行深化与突破，直到最终以代码来表达领域模型。排除技术因素的干扰：领域建模与技术实现的关注点分离有助于保证领域模型的纯粹性，也能避免混淆领域概念和其他只与技术相关的概念。模型驱动设计不能一蹴而就。毕竟，即使通过限界上下文降低了业务复杂度，对领域知识的理解是一个渐进的过程。在这个过程中，开发团队需要和领域专家紧密协作，共同研究领域知识。在获得领域模型之后，也要及时验证，确认领域模型有没有真实表达领域知识。一旦发现遗漏或失真的现象，就需要重构领域模型。首先建立领域模型，然后重构领域模型，进而精炼领域模型，保证领域概念被直观而真实地表达为简单清晰的领域模型。显然，在战术设计阶段，模型驱动设计也应该是一个演进的不断完善的螺旋上升的循环过程。本文摘录于张逸老师新书《解构领域驱动设计》。