如何用 DDD 驱动开发团队的沟通与协作？

范畴驱动设计的焦点是“范畴”，是以要运用范畴驱动设计，从一起头就要让团队走到准确的点儿上。当我们组建好了团队之后，应该从哪里起头？不是 UI 原型设计、不是架构设计、也不是设计数据库，这些事情固然主要但却非最高优先级。试想，项目已经启动，团队却并不认识整个系统的方针和局限，未对系统的范畴需求杀青共识，那么项目斥地的航向是否会跟着时间的推移而逐渐偏离？用准确的方式做准确的事情，运用范畴驱动设计，就是要先识别问题域，进而为团队提炼杀青共识的范畴常识。

[原文来自：www.ii77.com]

要做到这一点，就离不开团队各个脚色的沟通与协作。客户的需求不是从一起头就生长在那边的，就似乎在茫茫丛林中的一棵树木，守候我们去“发现”它。相反，需求或者只是一粒种子，需要泥土、阳光与水分，在人们的精心呵护与培育下才能强壮成长。是以，我们无法“发现”需求，而是要和客户一路“培养”需求，并在这个培养过程中逐渐成熟。 [转载出处：www.ii77.com]

杀青共识

“培养”需求的过程需要双向的沟通、反馈，更要杀青对范畴常识懂得的共识。原始的需求是“哈姆雷特”，每小我心中都有一个“哈姆雷特”，若是没有准确的沟通与交流体式，团队杀青的所谓“需求一致”不外是一种假象而已。

因为每小我获得的信息分歧，常识配景分歧，又因为脚色分歧因而导致设想的上下文也不沟通，诸多的分歧使得我们在对话交流中似乎被蒙了双眼的瞽者，我们配合捕获的需求就宛如一头大象，各自只获得局部的常识，却自认为掌控了全局：

或许有人会认为客户提出的需求就应该是悉数，我们只需懂得客户的需求，然后积极响应这些需求即可。传统的斥地合作模式更妄图以合同的形式商定需求常识，要求甲、乙双方在一份沉甸甸的需求规格解说书上签书画押，如斯即可商定需求内容和界限，一旦发生超出该文档界限的调换，就需要将调换申请提交到需求调换..进行评审。这种体式从一起头就站不住脚，因为我们对客户需求的懂得，存在三个偏向的误差：

• 我们从客户那边认识到的需求，并非用户最终的需求；

• 若无有效的沟通体式，需求的懂得误差则会导致究竟天差地别；

• 懂得到的需求并没有揭示完整的范畴常识，从而导致范畴建模与设计显现认知障碍。

Jeff Patton 在《用户故事地图》中给出了一副漫画来描述共识杀青的问题。我在 ThoughtWorks 给客户开展 Inception 运动时，也使用了这幅漫画：

这幅漫画形象地示意了若何经由可视化的交流形式逐渐在多个脚色之间杀青共识的过程。正如前面所述，在团队交流中，每小我都或者成为“瞽者摸象的演员”。怎么避免认知误差？很简洁，就是要用可视化的体式示意出来，例如，画图、使用便签、编写用户故事或测试用例等都是主要的辅助手段。鄙人一课，我会连系着范畴场景剖析来讲解这些提炼范畴常识的手段。

可视化形式的交流能够让分歧脚色看到需求之间的差别。一旦明确了这些差别，就能够行使各自把握的常识互补不足去掉有余，最终获得人人都一致承认的需求，形成统一的认知模型。

团队协作

在软件斥地的分歧阶段，团队协作的体式与方针并不沟通。在项目的先启（Inception）阶段，团队成员对整个项目的需求完全一窍不通，此时与客户或范畴专家的沟通，应该首要专注于宏观层面的范畴常识，例如，系统愿景和方针、系统界限与局限，还有首要的需求功能与焦点买卖流程。在治理层面，还需要在先启阶段确定团队与好处相关人（包罗客户与范畴专家）的沟通体式。

先启阶段

在迅速斥地过程中，我们非常正视在项目之初开展的先启阶段，尤其是有客户介入的先启阶段，是最好的认识范畴常识的方式。若是团队采用范畴驱动设计，就能够在先启阶段运用计谋设计，竖立初步的统一说话，在识别出首要的史诗级故事与首要用户故事之后，进而识别出限界上下文，并竖立系统的逻辑架构与物理架构。

在先启阶段，与提炼范畴常识相关的运动如下图所示：

上图列出的七项运动存在显着的先后顺序。首先我们需要确定项目的好处相关人，并经由和这些好处相关人的沟通，来确定系统的买卖盼望与愿景。在盼望与愿景的焦点方针指导下，团队与客户才或者就问题域杀青配合懂得。这时，我们需要确定项目的当前状况与将来状况，从而确定项目的买卖局限。之后，就能够对需求进行分化了。在先启阶段，对需求的剖析不宜细致，是以需求分化能够从史诗级（Epic）到主故事级（Master）进行逐层划分，并最终在买卖局限内确定迭代斥地需要的主故事列表。

迭代斥地阶段

在迭代斥地阶段，针对迭代生命周期和用户故事生命周期能够开展分歧形式的沟通与协作。在这个过程中，所有沟通协作的要害点如下图所示：

迭代生命周期是针对迭代方针与局限进行需求剖析与沟通的过程。团队首先要认识本次迭代的方针，对迭代中的每个义务要竖立根基的范畴常识的懂得。在迭代斥地过程中，我们能够借鉴 Scrum 迅速治理的过程。

Scrum 要求团队在迭代起头之前召开规划会议，由产物负责人（Product Owner）在会议中向团队成员介绍息争释该迭代需要完成的用户故事，包罗用户故事的买卖逻辑与验收尺度。团队成员对用户故事有任何不解或疑心，都能够经由这个会议进行沟通，初步杀青范畴常识的共识。天天的站立会议要求产物负责人介入，这就使得斥地过程中或者显现的需求懂得问题可以实时获得解答。

Scrum Master 则经由天天的站立会议认识当前的迭代进度，并与产物负责人一路基于当进步度和迭代方针确定是否需要调整需求的优先级。迭代竣事后，团队需要召开迭代演示会议，除了斥地团队之外，该会议还能够邀请客户、最终用户以及范畴专家介入，由团队的测试人员演示当前迭代已经完成的功能。

这种产物演示的方式更轻易消弭用户、客户、范畴专家、产物负责人与团队在需求沟通与懂得上的误差。因为迭代周期往往较短，即使发现了因为需求懂得纷歧致导致的功能实现误差，也可以做到实时纠偏，从而可以将需求问题扼杀于摇篮之中。

每一个功能的实现、每一行代码的编写都是环绕着用户故事开展的，它是组成范畴常识的最根基单元。用户故事指导着斥地人员的斥地、测试人员的测试，其质量会直接影响范畴驱动设计的质量。

迅速方式非常正视发生在用户故事生命周期中的各个要害节点。对于用户故事的编写，迅速斥地实践强调买卖剖析人员与测试人员配合编写验收测试的主动化测试剧本，这在《实例化需求》一书中被称之为“活文档（Living Document）”。测试人员与需求剖析人员的合作，能够为需求剖析供应更多视察视角，尤其是非常场景的识别与验收尺度切实认。

当用户故事从需求剖析人员传递给斥地人员时，不管这个用户故事的描述是何等的正确和具体，都有或者导致常识流失。是以，在斥地人员领取了用户故事，并充裕懂得了用户故事描述的需求后，不要急仓促地起头编码实现，而是建议将需求剖析人员与测试人员叫过来，人人一路做一个极短时间的沟通与确认，我们称这一运动为“Kick Off”，这种体式实际就是对“瞽者摸象”问题的一种应对。

在这个沟经由程中，斥地人员应尽或者地多问需求剖析人员“为什么”，以索求用户故事带来的价格。只有如斯，斥地人员才能更好地舆解买卖逻辑与买卖划定。同时，斥地人员还要与测试人员再三确认验收尺度，以形成一种事实上的需求规约。

当斥地完成后，是否就意味着我们能够将实现的故事卡移交给测试呢？固然经由迭代斥地以及竖立特征团队已经大大地拉近了斥地人员与测试人员的距离，缩短了需求从斥地到测试的周期。但我们认为，有价格的沟通与交流怎么强调都不外分！磨刀不误砍柴工。

我们认为从斥地完成到测试起头也是一个要害节点，建议在这个要害节点再进行一次交流运动，即在斥地情况下，由斥地人员向需求剖析人员与测试人员“实地”演示方才完成的功能，并对照着验收尺度进行验收，我们称这个过程为“Desk Check”，是一个快速迷你的功能演示，目的是快速反馈，也削减了义务卡在斥地与测试之间频仍切换的沟通成本。

经由 Desk Check 的用户故事卡才会被移动到“待测试”，不消比及迭代竣事，更不消比及版本发布，只要斥地人员完成了用户故事，测试人员就应该在迭代周期内进行测试，未经由测试的用户故事其交付价格为 0，能够认为这张用户故事卡没有完成，这也是大多数迅速实践对所谓“完成（Done）”的界说。

无数研究与实践也证实了，点窜 Bug 的成本会跟着时间的推移而增加，若是在斥地完成后顿时对其进行测试，一旦发现了 Bug，斥地人员便可以快速响应，降低点窜 Bug 的成本。当然，测试的过程同样是沟通与交流的过程，是最有效的需求验证和质量保障的手段。

迅速思惟强调个别和团队的协作与沟通，强调快速反馈与实时响应。前面商量的这些迅速实践都是行之有效的沟通机制和交流手段，能够匡助团队对需求的懂得加倍周全、加倍正确。只有频仍的沟通，才能就买卖需求杀青整个团队的共识；只有精巧的协作，才能有助于人人一路提炼范畴常识，竖立统一说话；只有快速反馈，才能尽或者包管范畴模型与法式实现的一致。这些都是实践范畴驱动设计的根基前提。

为什么要进修范畴驱动设计

若是你已经能设计出艳丽优良的软件架构，若是你只进展踏踏实实做一名高效编码的法式员，若是你是一位留意用户体验的前端设计人员，若是你负责的软件系统并不复杂，那么，你的确不需要进修范畴驱动设计！

范畴驱动设计当然并非“银弹”，天然也不是解决所有疑难杂症的“灵丹妙药”，请事先降低对范畴驱动设计的错误实际的盼望。我以中肯地立场总结了范畴驱动设计或者会给你带来的收获：

• 范畴驱动设计是一套完整而系统的设计方式，它能带给你从计谋设计到战术设计的规范过程，使得你的设计思路可以加倍清楚，设计过程加倍规范。

• 范畴驱动设计尤其擅长处理与范畴相关的高复杂度买卖的产物研发，经由它能够为你的产物竖立一个焦点而不乱的范畴模型内核，有利于范畴常识的传递与传承。

• 范畴驱动设计强调团队与范畴专家的合作，可以匡助团队竖立一个沟通精巧的团队组织，构建一致的架构系统。

• 范畴驱动设计强调对架构与模型的精心打磨，尤其擅长处理系统架构的演进设计。

• 范畴驱动设计的思惟、原则与模式有助于提高团队成员的面向对象设计能力与架构设计能力。

• 范畴驱动设计与微办事架构生成成家，无论是在新项目中设计微办事架构，照样将系统从单体架构演进到微办事设计，都能够遵循范畴驱动设计的架构原则。

  

人人好，我是张逸，客岁在 GitChat ..上上线了《范畴驱动计谋实践》的第一部门，累计销量已过 6000 份，同时建了两个读者群，也邀请了十几位范畴驱动设计方面的专家到场到了读者群，配合商量和交流范畴驱动设计的相关常识。

至今，两个群依然很活跃，天天都有很多问题抛出，同时又有很多问题获得认识答，还有更多的问题悬而未决，因为每小我都有本身心目中的“哈姆雷特”，谁也无法说服对方，谁也无法给出一个让所有人都认同的尺度谜底。这恰恰是范畴驱动设计最棘手的一部门，当然，也是最让人神往的一部门——唯有不确定，刚刚值得去索求。

在商量范畴驱动战术设计的一些问题时，总会有人纠结：这个范畴对象应该界说成实体，照样值对象？范畴办事和应用办事的区别是什么？聚合的界限该怎么划分？于是，各类设计问题接踵而至，问题越辩越糊涂，到了最后，已经离开了最初商量问题的场景，酿成了“空对空导弹”一阵乱发射，最后蓦然回首，才发现方针已然消散了。

这是错误理的。在软件斥地范畴，没有什么一劳永逸的实现，也没有什么放之四海而皆准的尺度，必需连系具体的买卖场景做出合理的决议，无论建模和设计再怎么完美，也需要经由落地的磨练才知道好照样坏。任何离开具体买卖场景的问题剖析，都是空口说；任何不落地的完美方案，都是夸张。范畴驱动设计没有尺度，有的只是持续络续的不确定性。

正所谓“以不变应万变”，我们要从实证主义的角度对待范畴驱动设计，窃认为，只需守住三项根基原则即可：

• 必需经由范畴建模来驱动设计

• 范畴专家或买卖剖析师必需介入到建模运动中

• 设计必需遵循面向对象剖析和设计的思惟与原则

只要做到这三点，范畴驱动战术设计就不会做得太差，剩下的不足，就需要靠经验来填补了。

本专栏由两个部门构成，第一部门内容周全笼盖了范畴建模剖析与架构设计的计谋设计过程，从理会软件复杂度的根源起头，引入了范畴场景剖析与迅速项目实践，匡助需求剖析人员与软件设计人员剖析软件系统的问题域，提炼真实表达的范畴常识，最终竖立系统的统一说话。同时，将主流架构设计思惟、微办事架构设计原则与范畴驱动设计中属于计谋设计层面的限界上下文、上下文映射、分层架构连系起来，完成从需求到架构设计再到构建代码模型的架构全过程。

第二部门内容要解决的则是前面所说起的战术层面的设计问题。单以战术设计阶段来看，我小我认为 Eric Evans 做出的进献并不多。在《范畴驱动设计》一书中，他讲到了模型驱动设计与范畴建模，却没有深入阐述该若何准确地进行范畴建模；他引入的资源库模式和工场模式，不外是面向对象设计原则的施展；至于模型的演化与重构带来的冲破，其实更多是经验之谈，缺乏切实可行的方式。

弗成否认，若要做到优良的范畴驱动设计，建模和设计的经验是必弗成少的，这需要多年的项目实战打磨方可萃取而成，但若是在起头之初，能有一些更为具体的方式作为指引，或许能够让把握花样的周期大幅度缩短。此外，我还清楚地看到：很多范畴驱动设计的外行人，之所以迟迟不得其门而入，是因为他（她）们连最为根基的面向对象剖析和设计的能力都不具备，是以，无法懂得范畴驱动的战术设计要素也就无独有偶了。

要害在于，很多设计问题因为其不确定性，基本没有尺度谜底，没有任何人能给你指出明确的设计方式和设计思路。这时，就必需要吃透面向对象剖析和设计的思惟与原则，用它们来指导我们的设计，而不是古板的遵循范畴驱动设计的模式。

针对一些设计能力不足的斥地团队，若进展采用范畴驱动设计来改善设计和编码质量，往往会拔苗助长，做出来的是一锅“夹生饭”。从幻想角度讲，决意是否采用范畴驱动设计，不在于团队成员的能力凹凸，而在于买卖的复杂度。然而，我们又不得不面临实际，若是团队成员的设计能力差了，是做欠好范畴驱动设计的。

是以，我在专栏中，一方面分享了我的设计体验和方式，以匡助团队成员的成长，另一方面也给出了一个把持性强的设计过程，能够让根蒂相对微弱的斥地人员可以依样画葫芦，做出还算不错的设计与实现。

这些考虑匡助我确定了专栏的根基思路，即以能进修和模拟的战术设计方式来填补经验之不足，以设计思惟和设计原则作为指导来解决争议之问题，以可以落地的解决方案来施展范畴驱动设计之价格。

本专栏并非是对 Eric Evans《范畴驱动设计》的率由旧章，而是吸纳了范畴驱动设计社区的列位专家巨匠提出的进步常识，并连系我多年来运用范畴驱动设计收获的项目经验，同时还总结了本身在范畴驱动设计咨询与..中对各类疑心与问题的思虑与解答。专栏内容既遵循了范畴驱动设计的基本思惟，又有本身的独到看法；既给出了权势的范畴驱动常识阐释，又解答了在实践范畴驱动设计中最让人疑心的问题。

我强烈建议读者诸君要学会对设计的素质思虑，不要只限于对设计概念的把握，而要追求对设计原则与方式的融汇贯通。只有如斯，才能针对分歧的买卖场景天真地运用范畴驱动设计，而非像一个牵线木偶般遵循着僵硬的过程进行古板地设计。

分享交流

我们为本专栏的付费读者建立了微信交流群，以轻易更有针对性地商议课程相关问题，订阅后即可入群。阅读文章过程中有任何疑问随时能够跟其他小伙伴商议，或许直接向我提问（我看到后会复原）。

订阅小攻略：如今 成为年会员，即能够 3 折的价钱换购本专栏，而且全场 Chat 免费读！

点击阅读原文，查察更多试读章节