解读《领域驱动设计 软件核心复杂性应对之道》（一）

       最近学习了两遍《领域驱动设计 软件核心复杂性应对之道》。这本书是2000年出头由一个老外写的。然后经过了国人翻译。

 

      2000年出头，技术架构还没有现在这么多好用的工具，也没有云原生的概念。这几年，随着云原生、微服务概念的兴起。这本书又被大家重视了起来。因为书中的很多理念，在现在的技术背景下，有很多的指导意义。大道至简，一些形而上学的东西往往是比较难说清楚，也比较难悟透的。就像孔孟的好多经典语句，放在当下时代，对我们仍然有很大的指导意义。这本书就是试图在说软件开发里面的道理。

        开始读起来会有些别扭，但是入境之后，感觉还行，主要适应的作者的叙述方式即可。这本书，按照作者的说法，是一本为面向对象软件开发人员编写的数据。作者试图通过一些例子让大家理解。但是这些例子大都需要对例子背后的业务常识有较深的理解（毕竟DDD强调的是业务与系统的配套与融合）。而理解这本书就有点难了，再去理解一遍业务，就更费时间了。这往往也是开发人员最不愿意做的事情。我觉得这是这本书难啃的部分原因吧！

       张逸写了一本《解构领域驱动设计》。这本书，在试图用现代技术的思维解读领域驱动设计。大家可以参考学习。但是学习二手的，不如学习一手的。这样也好有自己的理解。可以两本书结合着看，但重点还是读好原著。

      作者在书中多次提到，领域驱动设计并不是要求一开始就设计出完美的系统。我们需要不断重构、不断精进。可以是对老系统进行领域驱动改造。也可以新系统直接使用领域驱动去设计。但谁也不能保证新系统在设计后，不会再次优化架构。本书只是在你优化时，给你提供一些指导思想罢了。重要的是思维方式，而不是最后的形态。因为架构总是在演进的，而方法论却可以一直陪伴我们。

      这本书共分为4部分。有几个重点的章节。作者也在绪论里提了，可以选读。

       第一部分，运用领域驱动模型

       该部分提出了领域驱动设计的目标，后续章节都围绕这些目标展开讨论

      第1章 消化知识

      我们需要不断的学习业务知识，并和系统现状结合，提炼出模型，这是一个长期的过程。模型一定要和最终的实现保持同步。模型只需要展示重要部分，体现主要矛盾，无需面面俱到。

      第2章 交流与语言的使用

      建立团队通用的沟通语言UBIQUITOUS LANGUAGE 。

      第3章 绑定模型与实现

     要把代码的编写与模型紧紧结合起来。模型不能是空中楼