学习 DDD 之消化知识

接触到DDD到现在已经有8个月份了，目前所维护的项目也是基于DDD的思想开发的，从一开始的无从下手，到现在游刃有余，学到不少东西，但是都是一些关键字和零散的知识，同时我也感受到了是因为我对项目越来越熟悉，熟能生巧导致我现在在做需求的时候根本不用过多的去思考，就能很好的完成业务需求，我慢慢的意识到，学习DDD是非常有必要的。

在传统的开发模式中，产品经理在跟业务专家沟通业务需求后，对其进行抽象并将结果通过口头或者项目管理工具传达到开发人员，开发人员根据产品经理传递的业务需求机械式地进行功能开发，这样的模式使开发人员没有真正的理解业务原理，开发出来的功能就很难达到业务方的要求，即使达到要求也难以应对未来的业务变化。

如果大家都运用DDD的思想进行开发，就能很好的传递业务知识，因为DDD倡导开发人员、产品经理、领域专业一起讨论、消化业务知识，彻底理解业务原理。

以下是我在学习DDD时做的一些笔记，并整理成思维导图的形式，这样就能很好的形成结构化的思维，希望能让大家对DDD有一个更深的理解。

以下内容部分摘自 《领域驱动设计》和根据自己的理解整理而成。

1.1 有效建模的要素

模型和现实绑定

开发人员与产品经理在讨论需求的时候，都会画一些草图和对草图做一些文字说明，这其实就是最初的模型。最初的原型虽然简陋，但它在模型与与实现之间建立了早期链接，而且在所有的后续迭代中我们一直在维护该链接。

建立一种基于模型的语言

1. 起初领域专家不得不向开发人员解释业务知识
2. 开发人员也必需向领域专家解释类图的含义
3. 随着项目的进展，双方都能够使用模型中的术语，并将它们组织成符合模型结构的语句 ，而且可以无需翻译就能互相理解要表达的意思

领域专家专注业务领域，开发人员专注开发，两个不同领域的人在没有形成统一语言的前提下是很难沟通的，比如电商领域专家抛出订单履约的概念的时候，不得不在解释什么是订单履约时，还得向开发人员翻译里面的各种名词，如果领域专家和开发人员知识对等，就能互相理解各自要表达的意思。

开发一个蕴含丰富知识的模型

1. 对象具有行和为强制性的规定
2. 模型并不仅仅是一种数据模型
3. 模型应包含各种类型的知识

提炼模型

在模型日趋完整的过程中，要提炼模型，要将新的概念添加到模型中，同时将不再使用的或者不重要的概念从模型中移除。

头脑风暴和实验

1. 语言和草图，再加上头脑风暴，将我们的讨论变成“模型实验室”在这些讨论中可以演示、尝试和判断上百种变化
2. 当团队走查场景时，口头表达本身就可以作为所提议模型的可行性测试，因为人们听到口头表达后，就能立即分辨出它是表达得清楚、简洁还是表达的笨拙

1.2 消化知识

高效的领域建模人员是知识的消化者

建模人员需要从大量的信息中寻找有有的部分，然后不断的尝试各种信息组织方式，努力寻找对大量信息有意义的知识。

知识消化并非一项孤立的活动

1. 一般由开发人员领导下，由开发人员与领域专家组成团队来共同协作。
2. 共同收集信息，并通过消化而将它们组织为有用的形式
3. 信息的原始资源来自领域专家头脑中的知识、现有用户、以及技术团队在相关遗留系统或者同领域其他项目中积累的经验

传统瀑布模式的不足

业务专家与分析员（产品经理）进行讨论，分析员消化理解这些业务知识后，对其进行抽象并将结果传递给程序员，再由程序员编写软件代码。

1. 这种方法完全没有反馈（程序员没有提供自己的想法）
2. 分析员全权负责创建模型，但他们创建的模型只是基于业务专家的建议
3. 分析员没有向程序员学习，得不到早期版本的经验
4. 知识只是朝一个方向流动，不会累积

领域专家与开发人同一起消化理解模型的好处

在团队所有成员一起消化理解模型的过程中，他们之间的交互也会发生变化。

1. 领域模型的不断精化迫使开发人员学习重要的业务原理，而不是机械地进行功能开发
2. 领域专家被迫提炼自己已知道的重要知识的过程往往也是完善其自身理解的过程，而且他们会渐渐理解软件项目所必需的概念严谨性。

小结

开发人员、分析员、领域专家，都应该将自己的知识输入到模型中，这样模型的组织更严密，抽象也更为整洁。

模型不断改进的同时 ，也成为组织项目信息流的工具。模型聚焦于需求分析，它与编码和设计紧密交互。

1.3 持续学习

当开始编写软件时，其实我们所知甚少

项目知识零散地分散在很多人和文档中，其中夹杂着其他一些无用的信息，因此我们甚至不知道哪些知识是真正需要的知识。

看起来没有什么技术难度的领域很可能是一种错觉 -- 我们并没有意识到不知道的东西究竟有多少。这种无知往往会导致我们做出错误的判断。

所有的项目都会丢失知识

1. 已经学到了一些知识的人可能去干别的事了
2. 团队由于重组而被拆散，这导致知识又被重新分散开
3. 被外包出去的关键子系统可能只交回了代码，而不会将知识传递回来

当使用典型的设计方法时，代码和文档不会以一种有用的形式表示出这些来之不易的知识。因此一但由于某些原因团队成员没有口头传递知识，那么知识就会丢失。

高效率的团队需要有意识地积累知识，并持续学习

对于开发人员来说， 这意味着既要完善技术知识，也要培养一般的领域建模技巧。但这也包括认真学习他们正在正在从事的特定领域知识。

那些善于自学的团队成员会成为团队的中坚力量，涉及最关键领域的开发任务要靠他们来攻克。这个核心团队头脑中积累的知识使他们成为更高效的知识消化者。

1.4 知识丰富的设计

1. 业务活动和规则如同所涉及的实体一样，但是领域的核心，任何领域都有各种类别的概念。
2. 知识消化所产生的模式，能够反映出对知识的深层理解。
3. 在模型发生改变的同时，开发人员对实现进行重构，以便反映出模型的变化，这样，新知道就被合并到应用程序中了

1.5 深层模型

有用的模式很少停留在表面上， 随着对领域和应用程序需求的理解逐步加深，我们往往会丢最初看起来很重要的表面元素，或者切换它们的角度。这时，一些开始不可能发现的巧妙抽象就会渐渐的浮出水面， 而它们恰恰切中问题的要害。

推荐

• 分享一套家庭理财系统（附源码）
• 推荐一套开源通用后台管理系统（附源码）
• 推荐一个酷炫的监控系统
• 从朋友那里搞了 20 个实战项目，速领！
• 推荐一个完善的停车管理系统，物联网项目springboot，附源码
• 推荐一个互联网企业级别的开源支付系统
• 一款神仙接私活儿软件，吊到不行！
• 推荐 10 款超实用的企业级开源应用！
• 开放平台 SDK 设计实践！
• “淘宝” 开放平台接口设计思路
• Spring中经典的9种设计模式