关于ddd:学习-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 种设计模式