《企业应用架构模式》（Patterns of Enterprise Application Architecture），是Martin Fowler的经典著作，也是企业应用架构领域的必读书。这本书，总结了企业应用开发中的各种架构模式，从分层架构、领域逻辑，到数据映射、Web表现，几乎涵盖了企业应用开发的方方面面。今天，就来聊聊这本书，它的核心内容、价值，以及为什么说它是架构领域的必读书。

先说说这本书的背景。《企业应用架构模式》，是Martin Fowler在2002年出版的，到现在，已经快20年了。虽然，这20年里，技术发生了翻天覆地的变化，从Java EE到Spring，从单体到微服务，从关系型数据库到NoSQL，从服务端渲染到前后端分离，但这本书里讲的架构模式和设计思想，直到今天，依然适用，依然是企业应用开发的基础。

我第一次读这本书，是在工作几年之后，那时候，已经做了几个企业应用项目，积累了一些经验，但总觉得，自己的架构设计，不够系统，不够规范，很多时候，都是凭感觉，凭经验，没有一套完整的理论和模式支撑。后来，有人推荐了这本书，我读了之后，有种醍醐灌顶的感觉，很多以前模糊的概念，都清晰了，很多以前凭经验做的设计，都在这本书里，找到了理论依据和模式总结。

从那以后，这本书，就成了我的案头书，经常翻一翻，每次读，都有新的收获。今天，就把这本书的核心内容和价值，分享给大家。

一、这本书的核心内容

《企业应用架构模式》，内容非常丰富，全书分为两大部分，第一部分，是案例研究，通过一个具体的案例，展示了不同的架构模式，如何应用在实际项目中；第二部分，是模式详解，详细介绍了企业应用开发中的各种架构模式，每个模式，都有详细的说明、适用场景、优缺点、实现方式和示例代码。

第二部分，是这本书的核心，分为几个大的主题：

1. 分层架构

第一个主题，是分层架构。这是企业应用最基础、最核心的架构模式。Martin Fowler把企业应用，分为三个主要的层次：表现层（Presentation）、领域层（Domain）、数据源层（DataSource）。

  • 表现层：负责和用户交互，展示数据，接收用户输入，比如，Web页面、API接口、桌面GUI等。
  • 领域层：负责业务逻辑，是企业应用的核心，比如，业务规则、业务流程、领域模型等。
  • 数据源层：负责和数据存储交互，比如，数据库、消息队列、外部服务等。

分层架构的核心思想，是关注点分离，每个层次，只负责自己的事情，层次之间，通过接口通信，不直接依赖具体实现。这样，每个层次，都可以独立开发、独立测试、独立替换，大大提升了系统的可维护性和可扩展性。

Martin Fowler在书里，详细讲了分层架构的原则、注意事项、常见的错误，以及如何在实际项目中，应用分层架构。这些内容，直到今天，依然是企业应用架构的基础，不管技术怎么变，分层的思想，都是适用的。

2. 领域逻辑模式

第二个主题，是领域逻辑模式。领域逻辑，是企业应用最复杂、最容易出问题的部分。Martin Fowler总结了三种主要的领域逻辑组织模式：

  • 事务脚本（Transaction Script）：把业务逻辑，组织成一个个的事务脚本，每个脚本，处理一个业务请求，从接收请求，到业务处理，到数据库操作，到返回结果，都在一个脚本里完成。这种模式，简单直接，容易理解，适合业务逻辑比较简单的应用。
  • 领域模型（Domain Model）：把业务逻辑，组织成一个面向对象的领域模型，模型里的对象，既有状态，又有行为，对象之间，通过关联和协作，完成业务逻辑。这种模式，适合业务逻辑比较复杂的应用，能更好地应对需求变化。
  • 表模块（Table Module）：介于事务脚本和领域模型之间，把业务逻辑，组织成一个个对应数据库表的模块，每个模块，处理一张表的业务逻辑。这种模式，适合和关系型数据库紧密结合的应用，在.NET平台，比较常见。

Martin Fowler在书里，详细讲了这三种模式的优缺点、适用场景、实现方式，以及如何选择。这些内容，对于设计企业应用的领域层，非常有指导意义。很多人，做企业应用，不知道业务逻辑该怎么组织，是写在Service里，还是写在Model里，读了这部分，就会有清晰的答案。

3. 对象关系映射（ORM）模式

第三个主题，是对象关系映射（ORM）模式。企业应用，用面向对象的方式，组织业务逻辑，但数据，存在关系型数据库里，对象和关系型数据库之间，存在阻抗不匹配的问题，需要一层映射，来解决这个问题。

Martin Fowler总结了几种主要的对象关系映射模式：

  • 行数据网关（Row Data Gateway）：一个对象，对应数据库里的一行数据，对象里的属性，对应表里的字段，对象的方法，就是对这行数据的操作。
  • 表数据网关（Table Data Gateway）：一个对象，对应数据库里的一张表，对象里的方法，就是对这张表的操作，比如，查询、插入、更新、删除。
  • 活动记录（Active Record）：一个领域对象，同时包含业务逻辑和数据访问逻辑，对象自己，负责把自己的数据，持久化到数据库里。
  • 数据映射器（Data Mapper）：把领域对象和数据库，完全分离，领域对象，只负责业务逻辑，不知道数据库的存在；数据映射器，负责把领域对象，映射到数据库里，负责数据的持久化和读取。

Martin Fowler在书里，详细讲了这几种模式的优缺点、适用场景、实现方式，以及如何处理关联、继承、查询等复杂的映射问题。这些内容，对于理解ORM框架的原理，以及如何设计数据访问层，非常有帮助。现在流行的Hibernate、MyBatis、Entity Framework等ORM框架，本质上，都是这些模式的实现。

4. Web表现模式

第四个主题，是Web表现模式。企业应用，很多都是Web应用，Web表现层，有其特殊的模式和挑战。Martin Fowler总结了几种主要的Web表现模式：

  • MVC（Model-View-Controller）：把Web应用，分为模型、视图、控制器三部分，模型负责业务逻辑和数据，视图负责展示，控制器负责接收请求，调用模型，选择视图。这是Web应用最经典的架构模式。
  • 前端控制器（Front Controller）：用一个统一的控制器，处理所有的请求，然后，根据请求的类型，分发给对应的处理器。这种模式，适合需要统一处理请求的应用，比如，统一鉴权、统一日志、统一异常处理等。
  • 应用控制器（Application Controller）：在前端控制器之后，加一个应用控制器，负责处理请求的分发和视图的选择，把请求处理逻辑，和控制器分离。
  • 模板视图（Template View）：用模板，来生成HTML页面，模板里，既有静态的HTML，又有动态的内容，运行的时候，把动态内容，填充到模板里，生成最终的HTML。这是最常见的视图实现方式。
  • 转换视图（Transform View）：把领域数据，转换成XML，然后，用XSLT，把XML转换成HTML。这种模式，适合数据和展示，需要严格分离的应用。
  • 两步视图（Two Step View）：把视图生成，分为两步，第一步，把领域数据，转换成逻辑视图；第二步，把逻辑视图，转换成具体的HTML。这种模式，适合需要支持多种展示格式，或者需要统一页面布局的应用。

Martin Fowler在书里，详细讲了这些Web表现模式的优缺点、适用场景、实现方式。这些内容，对于理解Web框架的原理，以及如何设计Web应用的表现层，非常有帮助。现在流行的Spring MVC、ASP.NET MVC、Django、Rails等Web框架，本质上，都是这些模式的实现。

5. 并发和会话模式

第五个主题，是并发和会话模式。企业应用，是多用户的，需要处理并发和会话状态。Martin Fowler总结了几种主要的并发和会话模式：

  • 乐观并发控制（Optimistic Concurrency Control）：假设并发冲突，很少发生，修改数据的时候，不加锁，提交的时候，检查数据，有没有被其他人修改过，如果没有，就提交；如果有，就回滚。这种模式，适合冲突少的场景，性能好。
  • 悲观并发控制（Pessimistic Concurrency Control）：假设并发冲突，经常发生，修改数据的时候，先加锁，防止其他人修改，修改完了，再释放锁。这种模式，适合冲突多的场景，一致性好，但性能差一些。
  • 会话状态（Session State）：如何管理用户的会话状态，是存在服务端，还是客户端，是存在内存里，还是数据库里，还是分布式缓存里。Martin Fowler总结了几种会话状态的管理模式，以及各自的优缺点。
  • 身份验证和授权：如何验证用户的身份，如何控制用户的权限，Martin Fowler也讲了一些常见的模式和做法。

这些内容，对于设计企业应用的并发控制和会话管理，非常有指导意义。

二、这本书的价值

《企业应用架构模式》，之所以能成为经典，成为架构领域的必读书，是因为它有以下几个方面的价值：

1. 建立了企业应用架构的知识体系

在这本书之前，企业应用开发，很多时候，都是凭经验，凭感觉，没有一套完整的知识体系和模式语言。Martin Fowler通过这本书，把企业应用开发中的各种架构模式，系统地总结了出来，建立了一套完整的知识体系和模式语言。

有了这套知识体系，开发者在设计企业应用的时候，就有了参考和依据，不再是凭感觉，而是可以根据项目的特点，选择合适的模式，组合起来，形成适合自己项目的架构。而且，开发者之间，也有了共同的语言，可以用模式的名字，来交流架构设计，比如，"我们用领域模型+数据映射器+MVC"，大家一听，就明白是什么意思了，大大提升了沟通效率。

2. 模式背后的设计思想，永不过时

这本书里讲的具体模式，可能会随着技术的发展，有些变化，但模式背后的设计思想，比如，关注点分离、面向接口编程、高内聚低耦合、单一职责、开闭原则等，是永不过时的。

不管技术怎么变，从单体到微服务，从服务端渲染到前后端分离，从关系型数据库到NoSQL，这些设计思想，都是适用的。读这本书，不只是学具体的模式，更重要的，是学习模式背后的设计思想，学会如何思考架构设计，如何权衡利弊，如何选择合适的方案。

很多人，读这本书，只记住了具体的模式，比如，事务脚本、领域模型、MVC等，但没有理解背后的设计思想，这样，技术一变，就不知道该怎么办了。只有理解了背后的设计思想，才能以不变应万变，不管技术怎么变，都能设计出好的架构。

3. 大量的实战经验和权衡分析

Martin Fowler是实战派的大师，这本书里的每个模式，都不是凭空想出来的，而是从大量的实战项目中，总结出来的。每个模式，都有详细的适用场景、优缺点、实现方式、注意事项，还有，和其他模式的对比和权衡。

比如，在讲领域逻辑模式的时候，Martin Fowler会告诉你，事务脚本，适合什么场景，有什么优点，有什么缺点；领域模型，适合什么场景，有什么优点，有什么缺点；表模块，适合什么场景，有什么优点，有什么缺点。然后，告诉你，在什么情况下，应该选哪个，为什么。

这种权衡分析，是非常有价值的。因为，架构设计，没有银弹，没有哪个模式，是最好的，只有最合适的。好的架构师，不是知道很多模式，而是知道，在什么情况下，应该用什么模式，如何权衡利弊，做出最合适的选择。这本书，在这方面，给了我们很好的示范。

4. 案例研究，展示了模式的实际应用

这本书的第一部分，是案例研究，通过一个具体的案例，展示了不同的架构模式，如何应用在实际项目中。Martin Fowler从一个简单的需求开始，一步步，展示了如何用不同的模式，来设计这个应用，每种模式，是怎么实现的，有什么优缺点，如何演进。

这个案例研究，非常有价值，因为它把第二部分的各种模式，串了起来，展示了在实际项目中，如何选择模式，如何组合模式，如何实现模式。很多人，读第二部分的模式，觉得每个模式，都看懂了，但不知道怎么用在实际项目中，读了第一部分的案例研究，就明白了。

而且，这个案例研究，也展示了架构设计的演进过程，不是一开始，就设计出完美的架构，而是根据需求的变化，一步步演进，从简单到复杂，从一种模式，演进到另一种模式。这对于我们做实际项目，非常有启发意义。

三、这本书的局限性

当然，这本书，也不是完美的，也有一些局限性：

1. 出版时间比较早，有些技术已经过时

这本书，是2002年出版的，到现在，快20年了，这20年里，技术发生了很大的变化。书里的一些示例代码，用的是比较老的技术，比如，Java的老版本、ASP.NET的老版本，现在看起来，有点过时了。还有，书里没有涉及到一些新的技术和架构，比如，微服务、云原生、NoSQL、容器、DevOps等。

但这并不影响这本书的价值，因为，这本书讲的，是架构模式和设计思想，不是具体的技术实现。具体的技术，会过时，但模式和思想，是永不过时的。而且，Martin Fowler后来，也写了很多新的文章和书，补充了新的技术和架构，比如，《微服务设计》等，可以结合起来读。

2. 内容比较深，需要一定的基础

这本书，内容比较深，不是入门书，需要有一定的企业应用开发经验，才能读懂，才能理解其中的价值。如果是刚入门的新手，没有做过企业应用项目，读这本书，可能会觉得，很抽象，很难懂，不知道在说什么。

所以，建议大家，在做了一两个企业应用项目，有了一定的经验之后，再来读这本书，这样，收获会更大。读的时候，要结合自己的项目经验，想想，自己的项目里，是不是遇到了类似的问题，是怎么解决的，书里的模式，是不是更好，这样，才能真正理解和吸收。

3. 有些模式，现在用得少了

书里的有些模式，在当时，比较常用，但现在，随着技术的发展，用得少了。比如，转换视图（用XSLT转换XML生成HTML），现在，很少有人用了；还有，一些比较复杂的对象关系映射模式，现在，有了成熟的ORM框架，不需要自己实现了。

但这也不影响这本书的价值，因为，即使这些模式，现在不用自己实现了，但了解它们的原理，还是很有必要的，能帮助我们，更好地理解和使用现有的框架和工具。而且，模式背后的设计思想，还是适用的。

四、如何读这本书

最后，给大家一些读这本书的建议：

1. 先读案例研究，再读模式详解

建议大家，先读第一部分的案例研究，对企业应用的架构模式，有一个整体的印象，知道这些模式，是怎么用在实际项目中的。然后，再读第二部分的模式详解，深入理解每个模式的细节。这样，读起来，会更容易理解，也更有兴趣。

2. 结合自己的项目经验读

读的时候，一定要结合自己的项目经验，想想，自己的项目里，是不是遇到了类似的问题，是怎么解决的，书里的模式，是不是更好，有什么可以借鉴的。这样，才能把书里的知识，和自己的经验结合起来，真正理解和吸收。

如果，你现在正在做一个企业应用项目，可以一边读，一边把书里的模式，应用到自己的项目中，这样，效果最好。

3. 不要死记硬背模式，要理解背后的思想

读这本书，不要死记硬背，有哪些模式，每个模式，是怎么实现的。更重要的，是理解每个模式背后的设计思想，为什么要有这个模式，它解决了什么问题，有什么优缺点，适用于什么场景，和其他模式，如何权衡。

只有理解了背后的思想，才能在实际项目中，灵活运用，而不是生搬硬套。而且，技术会变，模式会变，但设计思想，是永不过时的。

4. 多读几遍，每次都有新收获

这本书，内容很深，不是读一遍，就能完全理解的。建议大家，多读几遍，第一遍，通读，了解大概；第二遍，精读，深入理解每个模式；第三遍，结合自己的项目，思考如何应用。每次读，都会有新的收获。

而且，随着你经验的增长，不同的阶段，读这本书，会有不同的理解和收获。我自己，就是每隔一两年，就会翻一翻这本书，每次读，都有新的体会。

五、写在最后

《企业应用架构模式》，是Martin Fowler的经典著作，也是企业应用架构领域的必读书。这本书，系统地总结了企业应用开发中的各种架构模式，建立了一套完整的知识体系和模式语言，背后的设计思想，永不过时。虽然，出版时间比较早，有些技术已经过时，但它的价值，依然存在，直到今天，依然是每个企业应用开发者，应该读的书。

如果你是做企业应用开发的，如果你想提升自己的架构设计能力，如果你想系统地学习企业应用的架构模式，那我强烈推荐你，读一读这本书。相信我，读完之后，你一定会有很大的收获。

最后，用Martin Fowler的一句话，结束这篇文章："任何足够复杂的系统，都需要架构，而好的架构，来自于对模式的理解和运用。"愿我们都能，理解模式，运用模式，设计出好的架构。