一句话总结

软件开发本质上是一个建模的过程，软件工程的本质问题是业务需求的复杂性而不是具体使用什么框架或语言进行开发。基于领域的建模可以有效降低工程复杂度(因为领域模型是真实世界运行机制的表达)。
PS: 由于作者写本书的时间在上世纪90年代，书中的一些语言(Smalltalk)、架构(BS架构)不具备借鉴意义，但是书中对于领域的建模思想却历久弥新，经久不衰。

一些知识点

前人为了弥补二进制世界与现实世界的巨大鸿沟，将软件开发分割成“分析(领域建模)”、“设计(架构设计)”、“编程(编码、编译等具体实施)”等步骤，本书着重讲的是基于业务逻辑的分析与建模。
Brooks 写过一篇论文《没有银弹—软件工程的本质与非本质问题》：软件开发的本质问题是业务本身的复杂性、需求的持续变化等。这些问题难以因为具体技术的发展而得到解决。而非本质问题是关于开发语言、工具、基础设施的，可以随着技术的进步而解决。
随着技术的发展，软件需求日益复杂，因此面向复杂领域的建模技术越发重要，领域建模是有效降低工程复杂度的好方法，不随着时间推移而改变。
模型没有对错，只有哪个模型更适用。模型的选择会影响开发出系统的灵活性与可复用性(灵活性高会提高复用成本)，因此模型不需要最灵活而是从团队及未来的需求出发在灵活性与可复用性中取一个中点。
分析技术与软件技术应该相互独立：对领域的建模不依赖任何具体的技术设施，对领域的建模应该是面向接口(类型)而不是实现(类)的，因此领域的建模不仅仅是开发者需要参与，领域专家也需要参与。
对领域的建模目的是输出“概念模型”，这个模型不依赖任何技术细节。
软件开发一个重要的原则就是使软件的结构反应问题的结构。

详情

第一部分：分析模式

分析模式是指建立领域模型的过程。列举了作者参加过的重大项目建模过程，这些业务模型通常可以横跨多个领域(比如责任模式)，作者希望通过这些模式可以帮助开发者对自己的业务领域进行快速建模。**注：书中模式很多，像一本字典，不需要每个都看，重要的是要有建模思维。架构设计时应该关注本质问题而非框架细节。**书中说到那些模式有一部分与《设计模式》中的模式特别像，这两者存在本质上说的是同一个事