DDD相关教学知识文章，一般局限于单一的理论层面或单一的讲一个代码Demo，这对于学习来说很不友好。
我们可能看完每一个文章都感觉自己会了，但当你实践的过程中会发现在纯粹的代码和纯粹的理论之间存在着空白。DDD的理论是执行的参考，但是这些理论会对我们的实际完整需求落地流程产生怎么样的影响，不ddd又会怎么样，是空白的。我们不能无知着去盲目的DDD。
本文旨在在学习理论知实践教程之后，结合自己建设项目过程中跨越业务与技术侧的实战经验，记录总结扯扯DDD的理解。
从理论出发
理论指导我们不需要再自己整理，直接引用，如果你找到一篇好的理论讲解，一定要多读认真读，才能有所感悟：DDD - 一文读懂DDD领域驱动设计-阿里云开发者社区 (aliyun.com)
我们可以已经从各类博客知识网站大量的DDD理论文章中，“通读”DDD的概念和理论。
倒叙来说：实战中：
-
业务系统分工不同、业务本身的复杂度存在着差异；
-
不同分工的人员对于DDD的感受不同
如果不能理解DDD的产生原因，那对于DDD的实战会是根基不稳的。因为不理解理论创建者的用意，而仅仅根据八股文去生搬硬套，那不如不DDD（当然大结论上我认为一切系统你都应该去DDD，不论复杂与否），这和我们招聘时会看重经验年数是一样的，过程是价值本身。
不同的人员视角
从开发人员的角度来说：
- DDD是各种领域对象（聚合->聚合根、实体、值对象），是对业务建模映射到代码。这早在ORM框架诞生的初期，由Table->Entity的映射关系便已存在，DDD没什么新鲜的。
- DDD是一种编码规范，要求按不同的领域设计实现方式（如分层、六边适配，本质差不多）将代码规范的容纳好。
- DDD是一种部门/应用间通信协议，显式的约定/要求抽象出应用层对外提供你的部门/应用对外提供可信且定义准确的能力。
- DDD是有着较长开发（摸鱼撞钟）周期的行为。
从业务人员（专家）的角度来说：
- DDD给了我们一个可以遵从的方法论基础模板，规范的与开发人员平齐信息。在没有DDD的时候，业务与开发当然也是要进行沟通的，但那时的沟通依赖于自然语言的完全表述，表述的优劣受这个项目的业务人员的能力影响。通常要求开发人员本身就对这部分业务具有一定的了解与实践，否则从0开始的沟通往往进行数据小时级会议才能够保证开发人员进行开发任务的工作，并且这种工作从实践经验来看还存在着偏差与返工的风险。
- DDD可以加强我们的业务模型的健壮性，在我们与开发人员沟通的过程中，信息由原本的单向输出，变为了参会者都可以理解进行评审并提出意见，每个参会人员都升格为这个业务诉求的owner。
从研发组长/leader的角度来说：
- DDD的理论指导可以帮助我们沉淀有效的文档。传统的文档对于开发人员来说是一种负担，他们并不愿意进行文档的编写。即使编写也是在完成指标，且无法准确的编写出能够指导新人员从0开始上手你的模块的文档。而领域设计的流程提供了一个模板，这个模板要求你必须做一些文档准备才可以开始编程，并且这个模板从方法论的角度保障了对于0基础上手的支撑。
- DDD提供了一个成熟的方法论帮助我们总控需求侧和研发侧的评审，我们有了可以看得见摸得到的模型作为依据。在开发人员具备DDD参与能力的情况下，我们可以有效的通过领域设计模型，该画图画图，加深自己理解的同时将理解需求并设计的职责下放到个人。之后我们可以更加直观的对比模型进行开发设计的评审，而不必再过于劳累的深入每一个需求以保障设计质量。
- 我们的总控质量在缺少方法论与沉淀的时候，受自己的状态波动影响大，DDD有效的保障了高下限。
- DDD的项目中，可以有效地并发利用起每个人员。在传统需求研发过程中，作为总控，我们自己可以理解整个需求中涉及的多个子系统（或者说子域）在需求中需要适配其在系统的位置做出什么样的改变。然后我们需要将每个子系统的开发任务分配到人，这时会遇到的问题是，我遇到的通常是无法将一个子系统内的任务分发到几个人一起完成的。子系统内的开发任务多人协作是困难的，总是需要有强势的一方完成这个子系统的总体开发变更设计后，几个人才能够进入各自的开发。而这种层层嵌套的设计委派，会带来不确定性，作为组长/leader无法通过可控的需求开发评审会议得到一个结论，还需要持续的投入进入这个子系统内部的分封，才可能关闭掉这个开发设计事项。并且这时还会产生开发人员间的理解平齐问题，在我所处的公司内，总是会出现各人仅知道自己的一亩三分地的问题，在合流时暴露出问题。
从部门经理的角度来说：
- 我没做过
- 拉皮条领导会焦虑的询问进度，--针对于项目经理，所以一个普通人能看得懂的DDD下的领域模型有利于糊弄他们，安心药。也有利于我们产出有依据的百分比进度汇报供他们继续汇报。
有人说业务简单就不要上DDD，对吗？
为什么会有这个疑问
会有这个疑问我认为是以下两点导致的
1、混淆了业务层面的简单与开发层面的简单
2、未理解到位DDD的目的
开发人员对于DDD的理解一般是code as design，更关注于代码层面。理解可能止步于理论指导的如何划分限界上下文、聚合，止步于提高编程的可读、通顺性。
开发人员理解并知道如何通过DDD这一规范进行代码编程，但是并不理解为什么要做DDD。
即使进行了DDD，可需求仍然是由领域专家和业务专家评审后，通过领域模型中的一些或行为或过程变动以文档形式同步到开发人员。DDD切实的加强了这一步的信息传达效率与准确性，但对于开发人员来说，他们接收到的信息仍然是我要实现一个什么样的需求这个是没有变化的。
那么自然，在编码层面的领域设计比较单薄的场景下，会发出疑问：为什么要做领域设计，直接老套路Controller、Service、Repository不好吗？
不对
DDD是一种方法论，而不是一种开发框架、组件。
DDD的结果不是目的，进行DDD这个过程本身才是目的。
如果只有因为开发起来觉得没意义就不进行DDD，那么在【不同人员视角】中提到的各种问题又会再次出现。
诚然，在开发代码时如果业务简单仍然进行DDD，会有一种脱裤子放屁的感觉确，但仅因此就忘掉了DDD对于需求->可执行开发设计流程带来的优化，就是只想吃最后一个饼了。
比如我们举几个会带来的，开发不会在意去想的例子问题：
- 没有DDD，你能给出一个个大功能的合理可执行排期吗？可以踩住线吗？
- 你可以准确秒描述提供可靠的当前进度情况吗，对非专业人员提供数据。
- 开发完这个简单的需求/模块后，别人可以接手吗？
- 开发过程中，紧急的较高破坏性迭代你有把握或者依据来hold住设计吗？
- 开发过程中，与外部/其他功能的协作中，你有明确的方向来执行吗？
- 过半年进行迭代时，你还看得懂自己的代码或文档吗？准确率如何
- 在业务变得复杂后，你能够做出优秀的迭代设计吗
而这几个问题，如果实施DDD，是可以进行规避的。
在需求开发/项目不同阶段的DDD
DDD的本质是业务与开发的再融合：
- 在高速扩张期，或者在传统模式下，业务与研发是隔离的。我们可以不关注质量，简单培训后，需求人员将一个又一个功能点的形式拆分后，开发人员完成，经过测试流程上线，紧张的流水线作业。我们的系统确实满足了业务的需求，但是这时我们已经造出了一个自己都不完全理解的怪物，这个怪物可以帮我们开疆扩土占地盘。
即使没有DDD这么一套方法论来定框架，我们也是知道并有执行步骤去做一个系统、人员间该怎么协作是优雅的。但形势不容做最优解。
- 在守江山的时期，我们会发现：（1）增长养不起如此多的扩张人员了，系统或死或封存，这些人又无法作为合格的标准化零件投入到其它项目组，或者是其它项目组本身也不缺人；（2）扩张期造出的怪物系统无人能够掌控，我们在学习DDD后会很自然地想到一个词：我们需要“领域专家”。没有领域专家，每一个新的需求都需要专人办专事，这不是仅仅从人力考虑，即使只从职业素养来考虑也是无法接受的。
所以，业务必须Make Code Great Again，再次与研发融合在一起，技术人员不能仅仅做一个接口man，并且系统应该是自然语言易懂的。每一个人都应该成为自己系统/微服务的领域专家。
在这之后，是的，会迎来裁撤驿站，因为每个人都是领域专家后，业务和研发再融合了（这本就应该是常态），不再需要那么多人了，模式变为领域专家对业务专家一起梳理需求，慢下来一个个需求做，不再有那么多人堆积着写接口。
本部分不会再解释为什么该用DDD（请看不同视角部分），而仅是描述DDD的理论是如何分散在一个个过程中的（已存在/应该存在才对）。
项目需求/业务塑形阶段
早期纯粹需求调研与塑形
在传统的需求落地过程中，我们首选做的是梳理业务的流程，这个流程一般有着粗粒度的主干和细粒度的一个个子业务流程细节。在此过程中我们就应该开始形成我们的通用语言了，这无关于是否DDD，都应当进行术语语言的规范。
领域设计要求现实对象与代码世界的对象一一对应，在接触需求的时候，我们可以接触到业务的直接使用者、操作者、提出者，这正是一个进行领域建模的好机会。进行DDD我们可以在需求阶段就直接将现实对象映射出领域对象，将现实的一个个行为对应上领域对象的一个个能力，这实际将我们的研发部分总体设计提前了，更早的可以暴露出问题。
而且这种设计思想还可以有效的串联流程并传达给开发人员：如果不进行DDD，业务人员可能将真实的需求中的行为梳理为一个个接口（功能点）需求的形式，需求文档的描述可能是在某个功能内要增加一个支持xxx的接口调用交互，这使得我们的开发丢失了原始的业务理解，传递来的孤立需求对于研发人员来说，是无法有一个整体认知的，此时他们只能专注于自己的接口需求中去盲目的实现。
假设此时在建设一个0-1的项目，在业务人员完成基于DDD理念的业务梳理后，他应该与研发的leader或者称之为专有名词技术侧的“领域专家”进行沟通，保证领域专家通晓其梳理的领域模型。
实战上，对于这种0-1的建设，我更希望领域专家在梳理需求阶段就参与到需求侧与业务专家一同行动。即使业务专家做的至善至美，他梳理的业务模型是完备的，但对于零基础的人来说要快速准确通晓其（业务专家）设计是不可能的，这种通晓可靠来自于长期深入需求调研的过程的积累。如果没有这种积累，很难保证后续的一些聚合、上下文、事件的设计可靠可信，也很难保证我们的研发和业务没有分头行动闭门造车。
假设此时在做项目进行时的一些需求迭代，那么是可以由业务专家梳理后，再与领域专家拉齐理解来评估领域设计的变化点有哪些，调整我们的模型。因为此前我们已经有了一个成熟可靠的模型，有着对于业务的足量理解，所以增量同步信息是可行的。
可能业务需求的评审已经存在研发参与这样的流程了，比较可能不存在的是需求参与进研发的设计评审会议。从单向流动变为双向共通。
需求的研发（落地）层面塑形
业务专家纯粹的业务塑形完成后，我们可以说自己掌握了7成的【纯粹业务模型】。此时还需要与研发侧力量进行合作，将纯粹自然语言的业务转变为可以驱动代码执行的开发业务模型，在DDD中我们称之为领域模型（吧）。DDD最重要特性（之一）就是靠着自然语言与人类的天然亲和性跨域。
在落地过程中有遇到几个场景会受到DDD的帮助，这几个场景我想不好怎么有顺序的串联，所以零散的列出来：
1、与非专业人员/系统使用者的沟通 领导、使用者、业务人员、技术人员，思考的偏向是不同的。
实战中我们遇到了很多基层千奇百怪的操作落实差异导致的细节业务差异，在客户的视角里是系统全都要去支持。但是出于系统的纯净性、系统的职责定位，我们（承建公司）内部会自然而然地存在默认的哪些要做哪些不要做哪些该要求客户怎么做（整改）的共识，这个共识即使没有自动出现也不会占用很长时间去统一，总归是专业人员。
但是在要说服客户接受我们的共识时，遇到了问题，我们曾经和客户沟通过，以我们认为已经够简单的逻辑去说服客户，但是结果并不理想，客户很难去理解我们的考量。
我们不考虑其它政治、斗争的角度，仅从专业方面从DDD的理论来解释则是（1）我们没能形成足够自然的通用语言、术语，专业知识无法传递给他们，我们认为自己已经够白话文去讲了，但是对于非专业人员来说我们自认的白话文还是存在太多专业性的知识了，其仍然难以听懂。此时的改进点就存在于我们内部研发与业务的再融合后，产出的DDD模型上。（2）则是客户的脑力可能确实存在问题，不带有情感的说：人与人的脑力差异是客观存在的，环境的影响很大，如果客户处于一个不太好的职业位置，那她的脑力可能退化了，变成人菜瘾大无担当。此时我们只能很空的说：“努力推进，积极落实”
落实DDD后，我们会产出领域模型，有一个可视的领域模型、业务流程/行为图文文档参考。即使客户缺少专业知识，也可以在DDD要求下充满着自然语言的看图识字的文档中看到自己的业务形态，此时我们再指出我们不希望哪里出现分支、我们认为哪里的流程应该做什么样子，客户也可以见到这个分支的不“美丽”。
当然，前提是客户足够拟人。
最差的情况，你也有第三方看的清白的DDD沉淀资料来吵架
2、决策的参考依据
可以说，在纯粹的业务塑形阶段，是伊甸园。在伊甸园中，没有责任的牵扯，可以纯粹的关注于业务本身，我们忠诚于自己（业务人员）的职责做的是将业务陈述下来。
但是如果要进行后续的落地，就必须要进行转化与细化，即我们的子标题“研发层面的塑形”，期间不可避免的将遇到一个又一个决策性问题。
在实践中和SX客户（不止于客户，你的业务上游也可能是）打交道时，我们总是会遇到一些决策性问题，这些决策性问题往往是非技术悬而未决无人来决策的，原因可以分为3种：
- 来自于对于担责的回避
如果缺少一种类DDD的方法论来产出业务研发设计，并自证设计的合理性，那么决策者的人治将会承担着对整件事情的责任。但决策者通常不具备对于每个系统的充分理解，或者说决策者还可能不是专业人员。DDD将成为你与他们沟通的语言，并提供一种标准的做事方法模板产出设计文档作为责任的载体，不再由某个人担责。
并且说真的，即使抛开责任问题，直接看到领域模型设计文档、领域内外交互的业务行为的图，相比于为了完成而完成的孤立功能业务流程图、接口设计文档，很直观。作为大家（共同责任体）的共识结论更可靠，领域设计的规范强制我们完成了更可靠的细化。
- 来自于对于“尊严”的维护
在拉皮条的企业（划死）在传统企业中，一个组长/leader/领导，通常会有自己先入为主的判断，这个判断并不是他们拍脑袋的决定，而是他们依照成功的相关经验复用的结果。但判断总是有出错的时候，这种错误通常还是“又不是不能用”的级别，那么该如何温柔的反驳推翻呢？
即使你是对的，又怎么说服一个人呢？语言是无力的，DDD提供了一个模式，在领域设计时，每一个个体都是业务/系统的整体拥有者，你和领导会以一种真的平等的方式在头脑风暴中设计模型，此时领导的错误可以被温柔的指出并让其意识到，在这种场景下，真理摆在模型上不证自明，不再独属于独享全局信息的某个人。领导在形势所迫下不会维护尊严，可以“唉，不错小李说得对”，即采纳正确的方案。
写的过程还就有人送例子来：大部门烂完了，隔壁一个该被淘汰的部门经理，他对于一个保底定时触发的设计，居然是要你做一个独立jar应用托管到外部调度平台，这个jar运行后只做那个保底触发的业务逻辑，就stop了。从DDD完全不可理喻，为什么要重复建设应用能力，我的服务提供这个应用层出去给你调度就好了。
- 来自于能力的不足
这里的能力不足与第一·中说的脑力不足是不一样的。你的上游业务或者甲方，他们可能并不是此次建设方向的业务专家，但又必须因为其他原因坐在这个位置上。
自然最终导致了他们缺少对于自己业务模型的全面掌握，每一个齿轮都在勇闯天涯。这和传统场景下至少有上游可以兜底住对业务模型的掌握是不同的，客观上最终没有人能回答我们的疑问。
此时如果还是关注于一个个功能点、接口去探讨去设计，这个系统会走向失败。我们必须在这种场景下使用DDD的模式从0梳理一个全局（至少子系统全局）的愿景（或者说在DDD中称之为战略设计）。
在这种场景下，子标题的“决策”问题出现了：不够专业的上游和从0开始的研发/承建团队，赶鸭子上架梳理的业务模型，在真实的一个个问题决策时，我们事实上出现了无法对自己梳理的东西置信，我们连自己都不相信自己，上游甲方/业务也不敢轻易决策。而从理论上看如果采用DDD，其产物则可以在这种问题出现时，提供作为决策参考的依据以统一内部思想+说服其他相关方。
3、 此时的纯粹业务模型仍存在着可能的不合理设计隐患、细节模糊、歧义传达隐患。
- 歧义传达
没有理论（类DDD）的支撑引导，对业务进行的调研塑形尝试是没有章法的，你会得到一堆描述东一个西一个业务诉求的文档、你会知道这有一个场景那有一个差异，但是这些文档在我的经验中，无人愿意阅读，且无人真的清楚（编写者一周内就忘掉了）。方法论的缺失导致这些文档事实上成为了字典一样的东西。
我们曾在建设明确细节时让一个资深业务员来看，他说每个章节都很清楚你在描述什么业务，但他同时认为你的描述总是不准确的，你总是要和他解释一段后，他才会理解到“哦，这和我们做的xx业务是一回事，对的对的”。资深业务尚且如此，谈何指导正确的研发。
塑形后
通用语言的缺失使得每一个开发人员都无法取代，成为了自己工作功能“领域”内的国中之国，我们在任务紧急时无法扩张并发提升效率。
研发建设阶段
研发建设通常是被迫“敏捷”的，所以这里依旧不会有一个明显的时间线，而是一个个场景会受到DDD的改变。
在我们上个项目调研结束后，我们就遇到了业务诉求如何转成通用语言让研发也能够明白的问题。在DDD的理论中，通用语言本身是手段，但是实践过程中发现，通用语言其本身又是阻碍。
一个通用语言/自然语言具有丰富的随着背景变化而不同的含义，这个本质导致我们在使用调研参与人员们内部已经统一的通用语言编写业务说明书、向研发传递需求，研发在读取文档后并不能理解业务的样貌，少数明白的部分也会想象的与我们实际调研知道的不同。
并且如何将通用语言有效的传递给研发人员也是一个问题：参与调研的研发/业务专家可以做到技术业务两开花之总控，但是在会议上与将被分发任务的研发人员沟通时，我们很自然的说出一个个术语来描述他们要做的一个个业务是什么样的，这些术语都是真实存在的的，但是我们却没有一个手册（业务说明书未包含一个术语答疑的部分）让研发人员可以系统的了解这些术语和业务模型。沟通总是会耗费很长时间而且反复。
综合来说，一份通用语言与业务说明书的编写，最好与研发一同进行不要闭门造车。且结合足够的图示会大幅提升效率，这也是DDD的理念。
参差不齐的设计/代码水平
外包、正式，及其阶级内部不同个人 的水平都是参差不齐的。在实战过程中，我们没日没夜的勉强度过了了上一个大标题的通用语言障碍、业务转研发概设的障碍后，进入纯粹的研发设计阶段，仍然会受到阻力。这个阻力并非哪个人有意为之，其来源多种多样，对于我方公司则是从18年开始的新增人员质量下降、薪资竞争力下降、缺少淘汰机制、领导层能力及工程建设模式（拉皮条）的守旧共同导致。
这个阻力，有些可以通过DDD进行优化减少，有些则力所不能及唯有裁人招人摸奖。
如何让他们转变行为模式
中层领导作为承上启下PUA的一环，常说研发（后端）不能等到开发完了再给前端接口设计。这个说法是有道理的，是研发行动模式的病症体现。
当我们进行给到研发人员开发任务的步骤时，研发从来没有主动的，在会议上总是要由业务专家/研发的leader对于业务进行总体串联，研发人员被动接受。有时最后的改造涉及功能点/接口总结、他们该做哪些设计，也都需要我们进行输入。
这里存在着两种情况，一种是研发人员素质确实不足，只能做最基础的开发任务，一般是外包人员，这个我们不做讨论（tmd想起来个正式也这B样，唉，淘汰机制，质疑理解成为互联网）。
另一种则是具备能力，但是无恶意的缺少动力。这类人你给他任务，不论大小都能比较好的完成，但是必须要有“你命他做某任务”这个象征性事件。他们在会议/评审中像是过客，在我们讲解传达信息后，他们能够理解，但是并不会自发的去设计，等你分配后/或明确这个部分极大概率归他维护，才会开始仅思考自己分得的任务涉及的部分。对于这种，DDD的方法论可以带来一些改变
- 在DDD的需求研发循环中，每位研发人都不再有一个明确的辖区边界（其实早于DDD便有轮班方法论），领域模型和业务模式对于每个人都是透明可见的，自然语言降低了参与进来讨论的壁垒。
- 在我们引导一揽子业务需求的传达时，他们必须关注于一切内容，每个人都被定义为这一堆需求的潜在责任人，这将有效的提升我们的会议效率和可靠性。说实话我受够了喝咖啡提神来引导这些需求了，集中式的设计对于主持人很累，并且责任压在一个人身上也是不可靠的设计；对于研发也是如此，他们在缺少透明全局信息的情况下开发，也容易陷入思维死循环和迷茫中，受个人性格影响大。
如何让子节点自治评审
如果你的系统由几位业务/研发专家来总控，便会遇到总控的效率瓶颈。因为在低效低质的传统需求传达模式下，总控者承担了7成的设计任务，研发人员实际上只承担了剩下的3成将设计代码化的任务。
DDD将带来的改变在于总控者的设计颗粒度：当然总控者依旧必须存在，责任只会变换形态而不会消失。在传统模式中总控者的瓶颈落到实处在于其对于基层研发无法放心，必须进行足够细致的设计管控，这个细致程度用代码语言表述为细到每一个service方法甚至于半步入参。
而在DDD后从我的经验来说，我们的评审将变为画图说话，图即设计，我们依旧用进行总控，但是控制的东西变为了业务行为图画完后，进行各子域的模型变更设计：你的上下文划分是否正确、聚合是否臃肿、能力增减是否不合理。如果研发给力这就是个过场，可算是用起来研发自己的脑子了。
原先的模式下1、没有第二个研发知道全局我们是无法将Sub一揽子需求给到某位研发去推动的，依旧需要总控的参与。按照DDD的模式，我们也可以终于分封下放总控责任了，只需要旁听最后双检他们的结论。2、下方分封后对方研发不知道如何上报评审，实战中会报上来零散的这一个那一个接口改动、改个表、加个参数等等，DDD则是一个可遵循的执行路径。
应急设计能力与DDD
实战中不是一条流水线，而是充满着临时性的被迫“敏捷”。在评估每次敏捷的影响时，我们缺少参照物，而只能条件反射拉起会议，每次评审的可靠性经过实战证明也是不稳定的，时常出现会议上的各位都觉得无异议（也大概率是【行为模式】标题中说的没在思考），但之后的研发执行会中途抛出疑问或阻塞，进而牵一发动全身。
这便是方法论的缺失，导致我们在做事的时候只想着每一个基础的实例，缺少总体的把控，对于总体的把控高度依赖于个人在此时的头脑清醒程度。
DDD的出现可能正是有着老一辈工程师在此类事故的堆积中的感悟总结。可以保证我们在应急改动设计时的下限，执行方法上强制要求我们进行基于领域模型系列文档的改动设计评审，并设计先行可视文档沉淀，可以有效地避免出现实战中的场景：如今天改了一个紧急支持，过了2周就忘了（这个忘，可以是文档结构的不成熟导致更新点被忽视，也可以是我们并没有人看文档所以按记忆去设计），然后第4周便成了另一个紧急需求的地雷。
总控人员长期投入协调
总监对于经理的训斥近期比较频繁，新的总监认为我们缺少方法论总是在盲目的忙，总是一个需求牵扯很多人累在那，这是正确的。
但是总监的论调总是纯粹的“管理”，而管理解决不了一切问题，尤其是假装有方法论实质上温和派PUA的管理。从DDD的理论来说，这是我们研发建设的崩塌，我们缺少足够的动力去执行满足最低研发要求外的一些方法论设计，对于研发来说并不值得为了领导的管理而去做设计做串联，最低成本的做法就是喊领导牵头介入。研发躺平，研发并不该具备主观能动性去进行为自己挖坟掘墓的知识共享语言共通，每一点阻碍不通都是在其部门的立身之本。DDD确实可以解决这个问题，但是涉及到利益的改革又会怎么样呢我不知道。
在项目实战中，这个问题具象化的体现是，我们虽然是一个研发团队，研发领命即了事，任何模块之间的沟通都需要总控的协调。在前2个月的建设过程中。我们作为总控还能hold住整个系统的各细节设计，但是随着进度加快推进，客户的催命夹杂上项目经理的焦虑有事没事要进度，我们开始逐渐无法有足够的时间和精力去理解整个系统的设计。我们的职能开始逐渐由总控向宦官滑坡，原本的总控设计评审滑坡至拉会、传达、要求会上做设计、假装思考然后结束。自然也开始出现上个标题中说的应急阻塞问题。
DDD从理论上要求每个人具有足够的系统领域模型认知，这里只能假设，如果当时成功推行DDD，可以保证低精力投入下依旧控制住全局设计，研发可以自行进行设计。
并且原先的研发执行中，也存在着研发想要去和外部模块沟通，但是不知道如何聊起，知识的独享是最大的问题。信息的缺失让人总是倾向于拖延！所以这个协调的职责被迫总控全部承担，反之DDD则是提供了共通的设计文档规则，降低了研发进行行动的门槛，我们有着一样的设计模式，那就让我看看你的你看看我的便可以开始沟通我们的交互变化。
在完成任务时，干活的人总是会消极的，除非你是胖东来的分配管理制度。DDD则是至少在理论层面给出了“降低门槛统一语言”的解决指导方针，至少可行性是没有问题的，那么在薪资回报体系不足的情况下又能怎么让干活的动起来呢？恐怕还真就只有温和派pua称兄道弟老哥哥了。这么想来，DDD本身就是用其先进方法论包裹的极温和派PUA。
项目经理慌的一批
DDD之所以不止造福于研发和需求专业内，在于它对各职责人员都具有天生的自然语言亲和性。
在进度压迫最紧张的前期（中后期也紧张），项目经理还有他的直属总监，一天内会三番五次（字面含义5次）询问进度。这个询问弄得我很无语，无语中夹杂着无助的愤怒，因为我们会发现无法回答他进度如何。
- 这个无助一方面是人员的投入原因，远程人员的进度我们无法实时掌握，总是要假定对方在摸鱼且不见面天然不会积极联系你进行沟通。
- 另一方面是即使我们自己主动询问现场人员和远端人员，也会脸面挂不住：因为我们可以询问的内容很尴尬，总是“这个功能怎么样了？什么时候能完成/能按期完成吗”。作为研发->研发头头和C++交际花->经理，我和我的经理都很清楚这种询问是无意义的，起不到帮助且会引起反感情绪起到反作用。
但我们又必须理解，项目经理的进度询问是必须的，他需要知道进度的风险情况，他也需要向上进行汇报。既然是合理的，那为什么给出进度会变得如此困难呢？我的理解是和上文中提到的问题一致：
- 需求、研发设计都在各个功能内孤立，而功能间事实上不是孤立的
- 研发自己就是国中之国，这是立身之本
- 研发并不该具备主观能动性去进行为自己挖坟掘墓的知识共享语言共通
导致了即使研发人员想回答我们进度，也只能说做到哪个接口哪个部分了，而这个“部分”的所处位置，并没有可以进行比对的总体需求流程可视参照物。就这样，项目经理的进度询问逐级传递到了研发身上，研发无法给出一个自己能保证的百分比进度。会议上吵起来过几次就是因为这种进度询问的强制性。
而从DDD的理论中，可以看到改变的可能，行为被抽象，能力被标明，模型是清晰的，可以有依据的统计你的能力改动/建设百分比。项目经理在这种模式下可以直接统计研发进度，而不必再由研发组长/leader做中间人，其时间可以解放去做更多的必要总控类支撑，我们遇到过的每个人都在受2头气的现象将得到优化。
评估时间排期与领域划分阶段
除了项目经理对于进度的频繁询问，我们在需求转进研发阶段时，还会遇到排期问题。
排期排期，抛开其他因素导致的排期倒排，要如何做到合理的排期规划？在我们传统的设计->实现过程中，功能（或者领域驱动中叫做能力）的研发间依赖关系被隐藏了，并且功能级别的划分模糊了功能内实际存在的领域设计复杂程度，我们无法给出合理的排期，因为我们并没有进行详细设计（这是常态）。
那么此时我们必须交出的排期，便是一个经验数据，在实践中也是如此，陪同评审排期是否可以完成的研发人员很无奈的接受了排期，他们并不知道是否真的如期完成，在一种职权压迫下立下了“按期完成otherwise自己加班”的军令状。
DDD的理论下，详细设计实际上被提前到了领域模型的梳理阶段，从纯粹的研发内部事务提前到了需求研发交界处。当我们交出一个合格的领域模型设计时，便已经将详细的能力拆分完成了，这些能力便可以以一个平均值进行排期预估，对于管理者与研发执行者都有好处。
