学习 DDD 之消化知识

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

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

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

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

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

1.1 有效建模的要素

模型和现实绑定

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

建立一种基于模型的语言

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

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

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

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