本篇详细讲述我在2021.10.30日，对于领域驱动设计的看法。
我认为所有事情是联结在一起的，从洗漱时先刷牙还是先洗脸，到设计上先短期还是先长远，直到实践上细节抽象的争论。
先说结论，领域驱动设计(DDD,aka Domain Driven Design),是一个结果，而不是一个工具，它并不像Git那般，今日决定大家使用Git进行代码管理，经过多日准备后，即可完成。作为一个结果，就要从结果的角度看待DDD,因为有了这个结果，得到了更优的开发效率，更好的开发质量，更低的开发成本。若抛弃DDD这个名词，直接去追求这三个更好，也许会有另一种形态的结果。本质上DDD是一种容易形成的结果，这个结果是一种状态，它没有“完成”这个概念。
讲这些，是要将读者的目的，从“我如何得到DDD”,转向“DDD到底做了些什么，可以让我抄一抄，从而接近甚至达到三个更好的状态”。
开发是需求->设计->施工 这条线上混乱的飞线过程，我们已知的，无可辩驳的事实如下：
1.开发团队内人员，无论是哪个岗位，从进入团队开始上手，到稳住局面，需要时间，这个时间往往是很大的代价。
2.人员间的交流，从来是有损的，可以做到低损失率交流知识的人员，是稀缺资源。
3.“开发”这个事情本身是难以控制实质的，我们要效率，就会损失质量，得到的效率与损失的质量之间，不成正比。
4.“知识”的失传往往造成严重后果，进度与难度的评估严重依赖知识。
而一般的开发团队（典型的单个项目单个团队）面临外部压力如下：
1.质量难以把控的需求（有些是提炼过的，有些是原始的，非常的看缘分）
2.平均能力相对较差的团队（如果你认为现有团队能力较强，说明你不应该是团队负责人，真正有利可图的开发，总是使用较差团队完成较高难度项目，这个本质是利润空间）
3.有限的工期（变动空间不大，属不可抗力）
基于无可辩驳的事实与外部压力，我们可以发现最大的风险来自于两项：
1.内部知识管理不善导致内部成本飙升
2.外部需求变动或不可抗力变动，导致环境突变
总结这两项风险，前者看起来我们可以做些什么，后者看起来什么都做不了，但其中关系需点出：如果内部知识管理水平较高，导致内部成本低于行业均值，可提高抵抗外部变动风险的能力，也就本质上提高了整个项目盈利的期望。
最好的知识管理方式是什么，我认为是独裁。
作为中国人，我们基本都了解统一度量衡和语言后，带来的大一统便利，大一统本质上是降低了知识流通的成本，想要保存知识，必须降低其流通成本，必须进行统一，必须进行独裁。故要做些什么，必须先得到独裁权力，那么最好的，推动此事的负责人为项目经理或技术经理，或两者的一致行为（需一致利益）。
我们假定这个独裁者已经有了，团队的资源可以任意调动，那么相应的，为了管理好知识，需做到两件事情：
1.降低知识本身的难度
对于知识的产出者，我们称其为专家，一般是各路大佬，他们作为相关经验持有者，其原始产出往往带有较高的阅读理解门槛。作为独裁者，可要求其针对团队现状，给出简单能用的解释，以降低知识本身的理解难度。
2.统一知识交流的名词体系
对于知识的使用者，我们称其为知识消费者，一般是团队内依赖他人成果进行工作的人员。作为独裁者，可指定唯一的一份知识中心（实践上，一般是一份词汇解释表，交代团队内通用俚语）， 要求消费者使用知识中心来进行知识交流。
领域驱动设计中，“领域”指的一般是统一后的知识与持有这些知识的人，我们可以把它想象成一个市场，这个市场里货币是石头，货物是鱼干和树皮，鱼干和树皮的生产者与消费者自觉地进行货物交换，市场得以正常运行，这个市场，即是一种领域；新的人员来到这个市场，他仅需阅读市场规定（词汇解释表），即可开始行动。
领域形成后，至于“驱动设计”，便是自然而然的在词汇表中新增一个词汇，该词汇需要全体人员的认同与理解（独裁者有很多办法），那么驱动设计的本质是“领域”扩张。
以上讲的比较简单，但实践上做知识统一和知识市场，是需要强人进行独裁的，读者需自行判断自己的影响力是否足够。
最好的抗风险方法是什么，我认为是低成本。
这个很好理解，如果我的成本够低，那么成本没了就没了。
对齐到知识统一这个事情上，对于风险的抵抗主要来源于以下两点：
1.内部的统一词汇解释表，可以多大程度的反映外部实际
2.内部的统一词汇解释表，可以多大程度的降低成本
这两点往往是矛盾的，一个不太反映实际的词汇表，往往非常简单，可以降低很多内部成本，但在实际变化时，死的很快。
那么核心落实在词汇解释表的编纂上：
1.外部实际可能发生的变化，不会是无方向的（如果你看不到方向，请找对应行业的专业人士），务必要对外部变化进行一个方向预期，这个预期很容易准
2.词汇解释表需具有一定的复杂度，来增加逻辑丰富性，可针对性的向上一条的预期偏离
3.某些让人纠结的名词，如果它不影响整体的能跑，先砍掉（通常是体验，性能之类的东西）
这就是解决问题的方式了。
总结起来，领域驱动设计的内核是知识管理，而知识管理的核心，是独裁者的词汇编纂工作，它也是内外统一的风险管理工作，如果能得到复杂度较低的且足够贴合外部实际的词汇解释表，则可使得整个团队获得竞争优势。领域驱动设计使得开发团队管理问题变为复杂度处理问题，讲明白了上述的正向思路后，我们讲讲这个思路执行的风险点：
1.独裁者能否得到实际权力（你别看名，权你到底有没有
2.独裁者个人能力问题（如果独裁者能力显著低于行业平均，则很难救场
3.团队本身竞争力问题（这套思路可以救回来一定的竞争力，但不是神药
4.你需要DDD吗？（
一些开发团队并不直接面临市场无法考核其成效，不需要DDD
一些开发团队项目极其简单，不需要DDD
一些开发团队其知识已经是行业通用的，不需要DDD（本质是领域知识已完备，无需构建词汇解释表）
补充-项目与团队的关系
假如构建好了词汇解释表，已经花了不少成本，觉得很亏，怎么办。
对于项目：（进行到了即将上线，线上问题很多，项目成功只差临门一脚）的情况下，撕毁这个词汇表，拿到收益
对于团队：大家过惯了根据词汇解释表工作的日子，需坚持这个习惯，应对下一个项目
从这个角度看，是不是横竖不亏？领域驱动设计并不是在关注开发，而是在关注开发中的人。