“领域驱动设计”答疑（三）
DDD
问题：领域驱动设计要怎么学习？有哪些推荐书籍？
如前文所说，领域驱动设计不是一个完备的软件设计过程或方法，它设立了一个目标，然后只给出了部分方法。它依赖的基础是软件设计、编码的基本功以及演进式设计的工程能力。所以学习和实践领域驱动设计，起点是了解领域驱动设计是什么，然后根据需要补各种软件基本功，以及通过实践提高动手能力。
学习领域驱动设计，首先是阅读介绍领域驱动设计的书籍。
-
《领域驱动设计》： 领域驱动设计之父Eric Evans写的书；
-
《实现领域驱动设计》：Vaughn Vernon写的讲领域驱动设计实现的书，从案例的角度讲的，因此容易理解很多；
-
《领域驱动设计精粹》：Vaughn Vernon补充的一本领域驱动设计的quick start手册；
新学习领域驱动设计的同学可以从《领域驱动设计精粹》看起，然后再看看《领域驱动设计》和《实现领域驱动设计》。《实现领域驱动设计》围绕着案例讲，降低了领域驱动设计的学习难度，但是里面的例子相对简单，而且是JAVA领域的，其它领域的同学从这本书里面可以领会一下精神。
后文开始介绍需要在领域驱动设计之外补充的其它必备知识和技能。
关于软件建模，面向对象分析与设计的书：
-
《面向对象分析与设计》： Grady Booch。通过理论与案例系统讲解面向对象分析与设计的书。比较早的书，可以选择性的看，有助于了解面向对象分析与设计建模的方方面面；
-
《彩色UML建模》：Peter Coad。社区里经常提到的“四色建模方法”出自这本书；
-
《软件方法》：UMLChina 潘加宇所著，目前只有上册。是我目前看到的国内出版的把业务建模和需求分析讲的得很棒的一本书，最重要的是这本书里面很多幽默的段子让整本书读起来非常有趣。
关于软件建模有很多书，还有例如《企业应用架构模式》、《面向模式的架构体系》等等。上述所有的书出的年代早晚不一，有值得学习的地方，也有受限于时代的地方。有时间可以多看一些，作为积累。
最后想说的是，领域模型建的是否合适，其实和对业务的理解深度关系更大。模型之所以要加上”领域“两个字做前缀，意味着要优先从领域出发。因此多去学一些业务知识，多去想一下那些不一致不协调的业务问题和代码问题背后更深层次的原因，多问一些为什么，探寻对领域更深入的洞察，是领域建模的核心工作。
从模型到代码的实现模式：
-
《敏捷软件开发，原则模式与实践》：Robert C. Martin。就不用多介绍了。
-
《设计模式》：不用过多介绍，属于基本功。使用设计模式的时候最好能和领域结合起来，做到抽象是领域模型的一部分，能够用团队可理解的模型概念做解释。
-
《实现模式》：Kent Beck。实现模式位于设计模式与代码之间，它包括编写简洁、清晰、易扩展、易维护的代码的各个方面的最佳实践，回答很多为什么高手的代码要这样写的问题。
-
《Clean Code》：Robert C. Martin。不用再多介绍了。
从模型到代码落地，需要及格线以上的代码基本功，这方面的书很多，需要多看多练。写的好的代码很容易就能看出背后的模型和设计；而写的差的代码实现复杂度高，和模型很难对应起来，需要看很多代码后在再经过仔细推敲，才能明白背后的设计。
要让代码清晰的反应模型和设计，一方面需要具备一定的面向模型的代码实现模式，让代码能够显示化的表达模型中的概念、关系和约束；另一方面，代码要从细节处做到clean，包括结构和命名都要力求精益求精，能够自注释。
演进式设计
《演进式架构》：Neal Ford , Rebecca Parsons , Patrick Kua。介绍了演进式架构的必要性以及如何在具体的软件开发流程中实现演进式架构。
《重构》：Martin Flower。代码重构能力是实现领域模型持续演进的必备技能。不得不说重构一词现今被用的过于宽泛，怎么高效的重构，可以参考《高效重构：正确理解重构》
《测试驱动开发》：Kent Beck。演进式设计离不开良好的开发者测试。 最佳的开发者测试实践依旧推荐采用测试驱动开发方法。
《持续集成》：Martin Flower。持续集成现今已经是软件开发的标配了，如今更多关注的是如何持续的提升持续集成流水线的效率，希望这方面会有新的作品出来。
《持续交付》：Jez Humble。不用过多的介绍，DevOps的经典书籍。推荐追求实践的同学可以找一些Jenkins2的书一起看看。
领域模型的持续演进，建立在一定的演进式设计能力之上。而演进式设计是需要上述种种技术和工程能力作为基础。每个软件团队在这方面的能力不一，但是都应该把这方面的能力作为团队持续改进的内容，以此提高软件开发的整体效率和响应力。
作为咨询师，很多设计和重构工作的起点都是从改进团队工程效率开始。只有先帮团队把缺失的能力（例如高效易用的开发者测试环境）构建起来，把各种工程实践的反馈时间优化到可接受的时间内（例如构建和流水线的反馈速度至少优化到分钟级别），才能支撑起随后的演进式设计过程。
刻意练习
上面推荐的所有书籍都是本人亲测过的：） 其中有一些看第一遍的时候一知半解，也是过好久之后才领悟，甚至明白有些内容未必再适合时下或者自己的上下文。所以读万卷书须得行万里路，理论需要刻意练习的反馈，才能知道里面的门门道道，真真假假。
对于练习，社区里有不少领域驱动设计的workshop，有时间精力的话可以择优参加。不过此类workshop我没有亲自参加过，所以没法做进一步评价或推荐。但是一般情况下workshop受限于时间和培训师的经历，很难做到既全面又深入，所以学完后须得在自己的场景进行再转化才能实践。
最好的练习当然是能够在自己的工作领域中实践，但是大多数人的工作领域场景单一受限，如果能够自行多找些建模的编程练习去做，以及多和高手交流，也能达到事半功倍的效果。
相比之下，咨询师有个天然优势是可以接触到各种不同类型的复杂项目，所以从来不缺刻意练习的环境和动力。但是这不代表咨询师就一定能做好建模设计，结果取决于咨询师有多大意愿去学习和思考对应的业务知识，以及能够投入多少精力去探索最佳的设计方案。
