第一次接触本书是 18 年在某个小外包企业实习的时候，公司的 CEO 拿出这本书叫我好好读一读，当时因为不太适应那家公司严肃的氛围，所以待了几天也就辞工了，书也就自然而然还给了别人。 近几日因疫情严重，闲在家没事就从网上搞来了电子版，看到现在也就还剩 100 来页了，遂决定把尘封了一段时间的博客搬出来写写读后感。
相较于我之前看到的几本 compute science 的书籍，这本书很少给出具体的代码层面的建议，这也正应验了书的标题 - 领域驱动，而非技术驱动。以我的观点看来，作者从函数方法，类，模块以及设计和人员组织等各个层面上论述各种建模以及管理成本的手段。相比于推崇某种框架或编程语言，作者更加鼓励大家衡量各种框架和编程语言的成本与效益，选择更加适合自己领域模型的工具。
在这里，我想解释一下我为什么称框架以及各种编程语言为工具呢？我相信我的很多同行们都有自己非常青睐的语言，大家可能最初因为被语言的某些特性或者框架所吸引，然后渐渐成为了某种语言的坚定拥簇者。我偶尔就在网上看到各个语言的使用者在网上撕逼吧，类似于 “php 是世界上最好的语言” 之类的论调。在我的认知里，程序员是一个 problem solver，而各种框架和编程语言只是我们手中的工具，工具之间比较而言都有自己的优势与劣势，而且这种优势与劣势都是视问题领域而言的。在网络编程这块，我举一个不恰当的例子，ruby 、python 这类就像是一把电锯，java 则相比较而言像一把木锯子，但是这也只是效率上的衡量。所以相比于费劲心思钻研语言，我更倾向于学习与总结解决问题的方法论。随着技术的进步总会有更具效率地工具出现，但是解决问题的方法论却会日久弥坚。
我认为本书也就是在向读者展示编程时控制成本，提高效益的各种维度的方法论。首先，作为一个开发者的角度，变量与方法的命名如何隐藏细节，让人一目了然地明白方法做了什么？这也就是文中提及的 Intention-Revealing Interfaces。所谓 Intention-Revealing Interfaces 就是类以及方法等通过名字能够表达做了什么事，达成了什么效果，但是不反映是如何做的。从设计者的角度出发，选用何种框架以及如何划分模块，才能更好地突出核心领域模型，并且使开发过程中不会受到框架的各种限制，这涉及到 Bounded Context 等概念。再者，书中也描述了从管理者的角度如何使团队中的各个成员保持认知一致，而这关系到 Ubiquitous Language 等等。
我之前所在的团队因为项目的历史因素，存在单点问题，所以关于整个项目的很多认知只存在部分人的脑子里，每次分派任务的时候都存在部分同学不清楚上下文的情况。为了消除单点问题，我们将整个项目划分了模块，并给每个模块安排了 owner 以及 backup，但是在我离开团队的时候这项措施仍然面对很对阻碍。现在想想这些问题的出现一部分确实是因为资源的不足。同时，这大概也牵扯到我们大部分程序员的一个现象，大家相较于思考团队组织或项目的合理性，更愿意花时间钻研技术层面上的问题。我知道前者可能倾向于管理层面，大家可能并没有太多的权利。但是在我之前所在的团队，大家基本上都是有权利提出建议进行改变的，当然这也包括我。这个问题虽然不断困扰着大家，但是却在日常的开发过程中不断被忽视掉了。每次接到新需求时，都需要给新同学讲下上下文或者可能存在的坑点，但是很少有东西被固化下来。这也逼迫新同学不得不去看代码才能明白。当然我觉得接到新需求查看历史代码是必需的一个步骤，但是有目的性的查看源代码总是比盲目地查找更具效率。
总之，聊到这里，这本书是值得一读的。本书在衡量软件的优劣的维度上不只是性能好坏，而是软件所表达业务的领域模型的深度与准确性。好的领域模型是在开发以及与他人交流的过程中不断获得新的认知，再不断进行重构得到的。