领域驱动设计，读书笔记：1 序言

本系列文章是《领域驱动设计：软件核心复杂性应对之道》的读书笔记

原书作者：Eric Evans。我选择的是人民邮电出版社 2016年第2版

---

本篇包括了：译者序、序、前言、致谢、第一部分的前言

---

0：核心问题

    项目怎样才能确保成功

    什么样的软件才能为用户提供真正价值，即软件的核心

    什么样的团队才算优秀团队

    如何制定决策

    如何把握项目方向

    如何处理各种机会挑战

    如何对项目产生决定性影响

    项目的宏伟目标：能够满足后续需求、可以不断演进的系统

---

1：目标、前提、原因、模型

目标：

    在领域建模过程中不应该将概念和实现割裂

    领域建模的最大价值提供了一种“通用语言”，为开发人员和领域专家以及开发人员内部沟通带来便利

    领域建模并不是“先建模后实现”而是随着对系统理解的深入、需求的增加而不断迭代。即便最有经验的建模者也是在系统的“初始版本”完成之后才有最好的想法。

    本书为设计决策提供一个框架，为讨论设计提供一个标准技术词汇库。

    真正决定软件复杂性的是设计方法，当复杂性失控时，开发人员就无法很好的理解系统，也就没办法轻易安全的更改和扩展。

    复杂性来自于领域本身，而不是技术。即来自于用户的场景和需求。

    领域驱动设计是一种思维方式，也是一组优先任务，旨在加速那些复杂领域的软件项目开发。为了实现这一目标，本书给出了一套完整的设计实践、技术、原则。

    开发人员可以抽象的讨论设计原则，但是更自然而有效的方法是结合适当的场景下进行讨论。

    领域驱动设计的实际就是消化吸收大量知识，最后产生一个反映深层次领域知识并聚焦于关键概念的模型。

    团队了解DDD的最大好处在于，可以将领域模型作为项目沟通的核心，作为共同语言以进行更加充分的沟通，能够创建和模型一致的清晰实现。

前提：

    1：主要焦点是领域和领域逻辑

    2：复杂的领域设计应该基于模型

    3：遵循敏捷开发实践。静态文档和预先规划和设计加重了项目负担，敏捷则强调应对变更和不确定性的能力。极限编程中承认设计的重要性，但是反对预先设计。相反它将相当大的精力投入到促进沟通和提高项目快速变更能力上，在项目任何阶段对只用“最简单而管用的方案”，然后不断做小型重构和迭代。

    4：开发人员和领域专家密切协作。由于开发是迭代的，所以这种协作必选贯穿整个项目生命周期。

原因：

    模型被用来描绘人们关注的现实或想法的某个方面。模式是一种简化，是对现实的解释。是将与问题密切相关的方面抽象出来而忽略无关细节的方法。

    软件：为执行某项活动或实现某种需求的程序产出。软件所面对的问题，就是领域。

    为了开发满足需要的软件，开发团队必须掌握一整套与领域相关的知识体系。而这些知识和信息可能庞大的超乎想象，例如现代金融系统。而模型正是解决这些信息超载的工具。

    模型可以对知识进行选择性简化和有意义的结构化，从而让人更易理解也更专注于问题。

    图是一种很好的表达模型的方式，当然精心编写的代码和文字也可以达到这个目的。

---

2：现状：

失败案例：    

    第一个版本过早的僵化了，成为维护代价高昂的遗留系统

    建模和开发脱节，从而反复迭代并不能有效改进代码，反而由于开发人员不认可模型价值使得团队没有协作基础。

    极限编程强调了迭代和沟通，却没有强调模型和设计，而重构的难易程度又是取决于先前的设计，所以可能出现各种意外情况。持续重构对于没有严格设计原则的开发者会创建出大量难以修改的代码（写死），这恰好与敏捷精神相悖。而对意外需求的担心往往导致过度设计，而为了防止过度设计又容易陷入另一个极端-不敢做任何深入的设计思考。

    敏捷开发是典型的过程关注，而领域设计则更加关注问题的内核。因此两者结合才能使得整套运转机制更加实用。

    大多数开发者对领域知识不感兴趣，更不愿意扩展领域建模的能力。想反，技术人才更愿意从事精细的框架工作，视图用技术解决领域问题。

    书中一个非常好的例子：

    一个剪辑人员会尽力去选择没有杂质的片子。但是导演却更关注整体效果，如果一个镜头有一点瑕疵，但是对整体是好的，那么导演也会选用。但是这对于剪辑人员是难以想到的，因为他会担心别人指责他放任瑕疵。

    所以，技术人员如果仅仅关注技术本身，也许就无法看到全局的模型，从而造成整体效果不佳。

    事实上，科学工程以及管理领域，“复杂性”都是最热门的议题之一，所有人员都在想办法解决真实世界的复杂性。

    从极大复杂性中创建一个简洁有效的模型是会带来巨大成就感的。让系统变得井井有条可维护性高，并且扩展迭代容易，那么这个设计者价值会大大增加。

    

---

3：书本结构

第一部分：运用领域模型。说明基本目标，定义术语，明确用领域模型驱动沟通和设计指的是什么。

第二部分：模型驱动设计的构造块。将一些核心最佳实践抽象成标准模式，即构造块。这些标准术语可以促进沟通。讨论一些保持模型和实现之间持续一致且高效的设计决策。

第三部分：通过重构来加深理解。讨论如何将上一部分定义的标准模式组装成实际的模型。这里会强调一步步迭代的过程，先实现最基础的，再不断改进。过程中丰富模型，并重构代码让代码更深刻的反映模型。本部分还讨论一些指导保持正确方向的建模原则。

第四部分：战略设计。在大型复杂系统以及外部系统和遗留系统交互中。三个原则：上下文，提炼，大型结构。

模型的作用：

    领域模型并不是要简历一个尽可能符合现实的模型（太现实了会过于复杂）。就像纪录片也不会将所有细节展现出来一样。建模应该应该根据作用来选择建立方式。

    模型有三个基本作用：

    A: 模型和实现的相互影响

    B: 模型是团队的通用语言

    C: 模型是浓缩的知识

一二三章针对的就是这三个作用展开，同时论述了三者关系。

推荐从引言和第1章开始阅读，核心是2、3、4、14章。

高级读者可以跳过第一第二部分，直接阅读第三第四部分。

对于有基础的，可以跳跃式阅读，通过标题和粗体字即可以掌握重点。

---

4：读者

面向对象软件开发人员。需要一些基础知识：UML图、Java代码、极限编程。这些基础了解就好不求深入细节。

    一般开发者：学会用高级建模和设计技巧来解决实际问题。

    高级开发者或者专家：对处理领域问题的综合框架感兴趣，帮助团队保持正确方向，统一团队术语。

分析员：掌握领域和设计的关系，方便和团队进行协作。此外利用战略设计原则可以更有重点的组织工作。

项目经理：可以了解如何提高团队效率，对方向也有个大概了解。

---

特别注：

    克里斯托弗-亚历山大 是奥地利建筑师。代表作《建筑模式语言》对设计模式和极限编程有重要影响，可以考虑看一下。