企业应用架构模式[按需印刷]
![企业应用架构模式[按需印刷]](http://images.china-pub.com/ebook15001-20000/19923/zcover.jpg?2011-8-15 12:49:17)
点击看大图
基本信息
- 作者： （美）Martin Fowler
- 译者： 王怀民 周斌
- 丛书名： 软件工程技术丛书
- 出版社：机械工业出版社
- ISBN：7111143051
- 上架时间：2004-7-8
- 出版日期：2004 年7月
- 开本：16开
- 页码：384
- 版次：1-1
- 所属分类：
计算机 > 软件工程及软件方法学 > 综合
编辑推荐
面向对象大师Martin Fowler又一力作 ！本书里的每一个模式描述了一个在我们周围不断重复发生的问题，以及该问题的解决方案的核心。这样，你就能一次又一次地使用该方案而不必做重复劳动。
推荐阅读
内容简介回到顶部↑
本书作者是当今面向对象软件开发的权威，他在一组专家级合作者的帮助下，将40多种经常出现的解决方案转化成模式，最终写成这本能够应用于任何一种企业应用平台的、关于解决方案的、不可或缺的手册。本书获得了2003年度美国软件开发杂志图书类的生产效率奖和读者选择奖。本书分为两大部分。第一部分是关于如何开发企业应用的简单介绍。第二部分是本书的主体，是关于模式的详细参考手册，每个模式都给出使用方法和实现信息，并配以详细的Java代码或C#代码示例。此外，整本书中还用了大量UML图来进一步阐明有关概念。
本书是为致力于设计和构建企业应用的软件架构师、设计人员和编程人员而写的，同时也可作为高等院校计算机专业及软件学院相关课程的参考教材。
本书是为致力于设计和构建企业应用的软件架构师、设计人员和编程人员而写的，同时也可作为高等院校计算机专业及软件学院相关课程的参考教材。
作译者回到顶部↑
目录回到顶部↑
引言 1
0.1 架构 1
0.2 企业应用 2
0.3 企业应用的种类 3
0.4 关于性能的考虑 4
0.5 模式 6
0.5.1 模式的结构 7
0.5.2 模式的局限性 9
第一部分 表 述
第1章 分层 12
1.1 企业应用中层次的演化 13
1.2 三个基本层次 14
1.3 为各层选择运行环境 15
第2章 组织领域逻辑 19
2.1 抉择 22
2.2 服务层 23
第3章 映射到关系数据库 25
3.1 架构模式 25
3.2 行为问题 28
3.3 读取数据 29
0.1 架构 1
0.2 企业应用 2
0.3 企业应用的种类 3
0.4 关于性能的考虑 4
0.5 模式 6
0.5.1 模式的结构 7
0.5.2 模式的局限性 9
第一部分 表 述
第1章 分层 12
1.1 企业应用中层次的演化 13
1.2 三个基本层次 14
1.3 为各层选择运行环境 15
第2章 组织领域逻辑 19
2.1 抉择 22
2.2 服务层 23
第3章 映射到关系数据库 25
3.1 架构模式 25
3.2 行为问题 28
3.3 读取数据 29
前言回到顶部↑
前言：
1999年春天，我飞抵芝加哥为ThoughtWorks公司正在开发的一个项目担任顾问。ThoughtWorks是一个规模虽小但正在快速成长的应用开发公司。这个项目属于那种极富挑战性的企业级应用，它是一个后端租赁系统。简单说，它处理的是租户签字认可后所有与租赁有关的事务，包括发送账单、处理某些人对所租房屋资产的改造、追踪那些未按时缴纳账单的租户、指出如果某人提前归还资产应当如何处理等。在你意识到租赁合同极度复杂并且总在不断变化之前，这听起来好像并不太难实现。它的业务“逻辑”几乎不能套用任何已有的逻辑模式，因为那些“逻辑”归根到底是商人们为争夺生意而制定的，一些古怪的小改动都可能对赢得某笔交易起关键作用。因此，每次生意上的一点点胜利就意味着系统复杂性的又一次增加。
我对此类问题情有独钟：如何捕获这些复杂性，并设计一个面向对象的系统来处理它们。事实上，我一直坚信面向对象的最大优点在于它能够使复杂逻辑易于处理。为复杂业务逻辑开发一个良好的领域模型很困难，但在此问题中却是恰得其所。
当然，单纯的领域模型也并非灵丹妙药。我们的领域模型必须持久化到数据库中，但是与许多项目一样，我们当时使用的是关系数据库。我们还必须将该模型与用户界面关联起来，还要能支持远程应用程序对本软件的使用，同时还必须将我们的软件与第三方的软件包整合。这些工作都基于一种被称为J2EE的新技术，当时全世界没有人在这一方面有实战经验。
虽然J2EE是一项崭新的技术，但我们仍能从以往的经验中得到帮助。本人曾经长期使用C++、Smalltalk和CORBA来开发类似系统。ThoughtWorkers公司中许多人则有Forte方面的经验。可以说当时我们对关键架构已经有了思路，所要解决的仅是如何将之转化为J2EE实现。现在回过头来看三年前的设计，虽然它并不尽善尽美，但无疑经受住了时间的考验。
上述情况正是我撰写这本书的出发点。多年来，我曾看到过许多企业级应用项目。这些项目通常都包含相似的设计思路，这些设计思路已经被证明可以有效地处理企业应用中不可避免的复杂性。本书就是将这些设计思路升华为模式的一个起点。
本书分为两个部分，第一部分是一些叙述性的章节，它们主要讨论企业级应用程序设计中的一些重要议题。这些章节介绍了企业级应用程序架构的各种问题，并给出了大体的解决方案。而解决方案的细节则在本书的第二部分以模式的方式组织成文。这些模式仅仅是一些参考，我并不希望读者一页页地去细读。我的想法是：从头到尾将第一部分的叙述性章节读完，然后再根据兴趣和需求翻阅第二部分的有关章节。因此，本书是将简短的叙述和详尽的参考合二为一。
本书讨论的是企业级应用程序的设计。企业级应用程序涉及到大量复杂数据的显示、操纵和存储以及对这些数据进行处理的业务流程的自动化。典型的例子有预订系统、金融系统、物流补给系统以及其他种种驱动现代商业运作的系统。企业级应用和嵌入式系统、控制系统、电信系统或者桌面应用程序不同，它们有自己特有的挑战和解决方案。因此，如果你在上述那些非企业领域工作，本书对你并没有益处（除非想体会一下企业级应用程序是怎么一回事）。如果需要一本关于软件架构的通用性的书籍，我推荐[POSA]。
在构建企业级应用时有许多架构方面的问题。我想本书恐怕很难一一详细列举。在软件开发方面，本人是迭代开发方法的忠实信徒。迭代开发的核心在于只要软件对用户有用，就应当交付，即使这个软件当时并没有完成。虽然著书与编写软件之间存在诸多差异，但我认为在这一点上异曲同工。也就是说，虽然本书尚不全面，但已初具雏形，可以为读者提供有关企业级应用程序架构方面的有益建议（至少我认为如此）。本书讨论的主要议题是：
* 企业级应用程序的分层
* 构建领域（业务）逻辑
* 构建基于Web的用户界面
* 将内存模块（尤其是对象）关联到关系数据库
* 在无状态环境下处理会话状态
* 分布原则
可能本书未涉及到的议题更多。我很想撰写关于组织确认、合并消息和异步通信、安全、错误处理、集群、应用集成、架构重构、构建胖客户的用户界面等方面的书籍或文章。但是，由于时空限制以及思路尚未成熟，本书将不涉及上述内容。我只能希望在不久的将来能看到一些与这些工作相关的模式。也许我会撰写本书的第2卷并加入这些内容，或者是由其他人来补遗。
当然，基于消息的通信是相当重要的问题。在进行多应用程序集成时，人们正越来越多地用到异步的、基于消息的通信方法。即便是在同一应用程序内部，基于消息的通信也值得费上一些笔墨。
本书并非针对某一特定的软件平台。从20世纪80年代末到90年代初，我开始在基于Smalltalk、C++和CORBA的项目中使用这些模式。而20世纪90年代后期我在Java方面做了大量的工作，我发现这些模式可以很好地应用于较早的Java/CORBA系统和其后基于J2EE的工作中。近来，我开始在微软的.NET平台方面做一些探索，我发现这些模式同样有效。ThoughtWorkers公司的同事也介绍了他们的经验，尤其是在Forte方面。我不敢说这些模式能够通用于所有已经和即将被用于企业级应用的开发平台，但至少到目前为止，它们已经表现出足够的可重用性。
对于大多数模式，本书提供了相应的代码示例。这些例子所用的程序设计语言是我认为大多数读者都能够阅读和理解的语言。Java就是一个很好的选择。只要熟悉C或C++就可以读懂Java代码，Java远没有C++那么复杂。基本上，大多数C++程序员都能够理解Java，但反过来却并非如此。我是面向对象的信徒，也就自然更偏爱面向对象的语言。因此，大多数代码示例使用的是Java语言。写这本书时，微软的.NET环境正逐渐成熟，它的C#语言与Java有许多相同之处。所以某些代码示例也使用了C#语言，虽然这样做会多少有一些风险，因为.NET尚未得到大量应用，使用的术语可能尚未形成惯例。这两种语言都是基于C的语言，只要能读懂其中一种，即使对另一种语言或平台并不熟悉，要读懂它也并非难事。我的目的是使用一种能够让最多的软件开发者读懂的语言，即使这种语言并非他们所擅长或偏爱的。（谨向那些喜欢Smalltalk、Delphi、Visual Basic、Perl、Python、Ruby、COBOL或其他语言的读者致歉。我知道你们认为有比Java或C#更好的语言，我也认为如此！）
示例是用来阐述和解释模式思想的。它们并非可以直接使用的解决方案；任何情况下都需要做一些工作才能将它们用于你的应用程序之中。模式只是一个有益的起点，而非最终的解决之道。
1999年春天，我飞抵芝加哥为ThoughtWorks公司正在开发的一个项目担任顾问。ThoughtWorks是一个规模虽小但正在快速成长的应用开发公司。这个项目属于那种极富挑战性的企业级应用，它是一个后端租赁系统。简单说，它处理的是租户签字认可后所有与租赁有关的事务，包括发送账单、处理某些人对所租房屋资产的改造、追踪那些未按时缴纳账单的租户、指出如果某人提前归还资产应当如何处理等。在你意识到租赁合同极度复杂并且总在不断变化之前，这听起来好像并不太难实现。它的业务“逻辑”几乎不能套用任何已有的逻辑模式，因为那些“逻辑”归根到底是商人们为争夺生意而制定的，一些古怪的小改动都可能对赢得某笔交易起关键作用。因此，每次生意上的一点点胜利就意味着系统复杂性的又一次增加。
我对此类问题情有独钟：如何捕获这些复杂性，并设计一个面向对象的系统来处理它们。事实上，我一直坚信面向对象的最大优点在于它能够使复杂逻辑易于处理。为复杂业务逻辑开发一个良好的领域模型很困难，但在此问题中却是恰得其所。
当然，单纯的领域模型也并非灵丹妙药。我们的领域模型必须持久化到数据库中，但是与许多项目一样，我们当时使用的是关系数据库。我们还必须将该模型与用户界面关联起来，还要能支持远程应用程序对本软件的使用，同时还必须将我们的软件与第三方的软件包整合。这些工作都基于一种被称为J2EE的新技术，当时全世界没有人在这一方面有实战经验。
虽然J2EE是一项崭新的技术，但我们仍能从以往的经验中得到帮助。本人曾经长期使用C++、Smalltalk和CORBA来开发类似系统。ThoughtWorkers公司中许多人则有Forte方面的经验。可以说当时我们对关键架构已经有了思路，所要解决的仅是如何将之转化为J2EE实现。现在回过头来看三年前的设计，虽然它并不尽善尽美，但无疑经受住了时间的考验。
上述情况正是我撰写这本书的出发点。多年来，我曾看到过许多企业级应用项目。这些项目通常都包含相似的设计思路，这些设计思路已经被证明可以有效地处理企业应用中不可避免的复杂性。本书就是将这些设计思路升华为模式的一个起点。
本书分为两个部分，第一部分是一些叙述性的章节，它们主要讨论企业级应用程序设计中的一些重要议题。这些章节介绍了企业级应用程序架构的各种问题，并给出了大体的解决方案。而解决方案的细节则在本书的第二部分以模式的方式组织成文。这些模式仅仅是一些参考，我并不希望读者一页页地去细读。我的想法是：从头到尾将第一部分的叙述性章节读完，然后再根据兴趣和需求翻阅第二部分的有关章节。因此，本书是将简短的叙述和详尽的参考合二为一。
本书讨论的是企业级应用程序的设计。企业级应用程序涉及到大量复杂数据的显示、操纵和存储以及对这些数据进行处理的业务流程的自动化。典型的例子有预订系统、金融系统、物流补给系统以及其他种种驱动现代商业运作的系统。企业级应用和嵌入式系统、控制系统、电信系统或者桌面应用程序不同，它们有自己特有的挑战和解决方案。因此，如果你在上述那些非企业领域工作，本书对你并没有益处（除非想体会一下企业级应用程序是怎么一回事）。如果需要一本关于软件架构的通用性的书籍，我推荐[POSA]。
在构建企业级应用时有许多架构方面的问题。我想本书恐怕很难一一详细列举。在软件开发方面，本人是迭代开发方法的忠实信徒。迭代开发的核心在于只要软件对用户有用，就应当交付，即使这个软件当时并没有完成。虽然著书与编写软件之间存在诸多差异，但我认为在这一点上异曲同工。也就是说，虽然本书尚不全面，但已初具雏形，可以为读者提供有关企业级应用程序架构方面的有益建议（至少我认为如此）。本书讨论的主要议题是：
* 企业级应用程序的分层
* 构建领域（业务）逻辑
* 构建基于Web的用户界面
* 将内存模块（尤其是对象）关联到关系数据库
* 在无状态环境下处理会话状态
* 分布原则
可能本书未涉及到的议题更多。我很想撰写关于组织确认、合并消息和异步通信、安全、错误处理、集群、应用集成、架构重构、构建胖客户的用户界面等方面的书籍或文章。但是，由于时空限制以及思路尚未成熟，本书将不涉及上述内容。我只能希望在不久的将来能看到一些与这些工作相关的模式。也许我会撰写本书的第2卷并加入这些内容，或者是由其他人来补遗。
当然，基于消息的通信是相当重要的问题。在进行多应用程序集成时，人们正越来越多地用到异步的、基于消息的通信方法。即便是在同一应用程序内部，基于消息的通信也值得费上一些笔墨。
本书并非针对某一特定的软件平台。从20世纪80年代末到90年代初，我开始在基于Smalltalk、C++和CORBA的项目中使用这些模式。而20世纪90年代后期我在Java方面做了大量的工作，我发现这些模式可以很好地应用于较早的Java/CORBA系统和其后基于J2EE的工作中。近来，我开始在微软的.NET平台方面做一些探索，我发现这些模式同样有效。ThoughtWorkers公司的同事也介绍了他们的经验，尤其是在Forte方面。我不敢说这些模式能够通用于所有已经和即将被用于企业级应用的开发平台，但至少到目前为止，它们已经表现出足够的可重用性。
对于大多数模式，本书提供了相应的代码示例。这些例子所用的程序设计语言是我认为大多数读者都能够阅读和理解的语言。Java就是一个很好的选择。只要熟悉C或C++就可以读懂Java代码，Java远没有C++那么复杂。基本上，大多数C++程序员都能够理解Java，但反过来却并非如此。我是面向对象的信徒，也就自然更偏爱面向对象的语言。因此，大多数代码示例使用的是Java语言。写这本书时，微软的.NET环境正逐渐成熟，它的C#语言与Java有许多相同之处。所以某些代码示例也使用了C#语言，虽然这样做会多少有一些风险，因为.NET尚未得到大量应用，使用的术语可能尚未形成惯例。这两种语言都是基于C的语言，只要能读懂其中一种，即使对另一种语言或平台并不熟悉，要读懂它也并非难事。我的目的是使用一种能够让最多的软件开发者读懂的语言，即使这种语言并非他们所擅长或偏爱的。（谨向那些喜欢Smalltalk、Delphi、Visual Basic、Perl、Python、Ruby、COBOL或其他语言的读者致歉。我知道你们认为有比Java或C#更好的语言，我也认为如此！）
示例是用来阐述和解释模式思想的。它们并非可以直接使用的解决方案；任何情况下都需要做一些工作才能将它们用于你的应用程序之中。模式只是一个有益的起点，而非最终的解决之道。
序言回到顶部↑
译者序：
“每一个模式描述了一个在我们周围不断重复发生的问题，以及该问题的解决方案的核心。这样，你就能一次又一次地使用该方案而不必做重复劳动。”
—Christopher Alexander
本书是面向对象大师Martin Fowler继《Analysis Patterns》、《UML Distilled》、《Planning Extreme Programming》、《Refactoring》之后的又一力作。
“温故而知新”。Fowler在本书中再次向我们证明了《礼记》中这句古训的震撼力—他在回头审视自己及同仁多年来从事企业应用开发的经验和教训后，归纳总结了40多种企业应用架构的设计模式。这些模式从不同层次、不同侧面向我们展示了什么是好的企业应用架构？如何设计好的企业应用？
正如作者自己所言，企业应用在某些方面比其他软件（如电信通信软件）复杂得多：纷繁复杂的企业数据、“不合逻辑”的业务规则、变化莫测的用户需求，等等。环顾四周—CORBA、J2EE、.NET—企业应用开发技术可谓“前仆后继、层出不穷”，开发平台的种类之多就更不必说。
招式套路可以千变万化，扎实深厚的“内功”却是始终如一！虽然企业应用涉及的软件技术不断翻新，但是基本的架构及设计思想却没有太多变化。将以前行之有效的设计思路和方法加以适当调整，并应用到当前的问题上，是最高效的做法。在一组专家级合作者的帮助下，Martin将40多种经常出现的解决方案转化成模式，最终融会成这本“内功心法”。在仔细研读、用心揣摩本书之后，希望它能够帮助你应对任何一种企业应用平台，驾御任何一种企业应用技术—无论是现在的技术还是未来的技术。
熟悉Fowler的读者都知道，这位大师的写作风格可谓是“深入浅出，娓娓道来”。本书也是一样。前8章是关于企业应用的背景知识，如分层架构、Web表现、业务逻辑、数据库映射、并发、会话、分布策略，等等。在此基础上，随后的各章分别对与这些背景知识相关的设计模式进行了详细的介绍。与其他设计模式的书一样，本书从模式的使用场景、解决方案、UML表示等方面予以介绍，详略有致。就连示例的编程语言的选取—Java和C#—也是与他的写作风格一脉相承的。
夜已深，窗外依旧是绵绵不断的早春小雨。让我们酌一杯清茶，一起来品味大师的话，一起来品味“源于实践、指导实践”的苦涩与甘甜—
“模式的关键点是它们源于实践。必须观察人们的工作过程，发现其中好的设计，并找出‘这些解决方案的核心’。这不是一个简单的过程，但是一旦发现了某个模式，它将是非常有价值的。对于我来说，价值之一是能够撰写这样一本参考书。你不必通读本书的全部内容，也不必通读任何一本有关模式的书。只需要了解到这些模式都是干什么的、它们解决什么问题、它们是如何解决问题的，就足够了。这样，一旦你碰到类似问题，就可以从书中找出相应的模式。那时，你再深入了解相应的模式也为时不晚。”
本书翻译初稿的过程中得到了丁博、王树凤、朱锐、林繁、托明福的大力帮助。王怀民、周斌分别统审了全书。非常感谢UMLChina潘加宇、蒋芳在校对过程中的宝贵意见和建议。
译 者
2004年3月27日于长沙
“每一个模式描述了一个在我们周围不断重复发生的问题，以及该问题的解决方案的核心。这样，你就能一次又一次地使用该方案而不必做重复劳动。”
—Christopher Alexander
本书是面向对象大师Martin Fowler继《Analysis Patterns》、《UML Distilled》、《Planning Extreme Programming》、《Refactoring》之后的又一力作。
“温故而知新”。Fowler在本书中再次向我们证明了《礼记》中这句古训的震撼力—他在回头审视自己及同仁多年来从事企业应用开发的经验和教训后，归纳总结了40多种企业应用架构的设计模式。这些模式从不同层次、不同侧面向我们展示了什么是好的企业应用架构？如何设计好的企业应用？
正如作者自己所言，企业应用在某些方面比其他软件（如电信通信软件）复杂得多：纷繁复杂的企业数据、“不合逻辑”的业务规则、变化莫测的用户需求，等等。环顾四周—CORBA、J2EE、.NET—企业应用开发技术可谓“前仆后继、层出不穷”，开发平台的种类之多就更不必说。
招式套路可以千变万化，扎实深厚的“内功”却是始终如一！虽然企业应用涉及的软件技术不断翻新，但是基本的架构及设计思想却没有太多变化。将以前行之有效的设计思路和方法加以适当调整，并应用到当前的问题上，是最高效的做法。在一组专家级合作者的帮助下，Martin将40多种经常出现的解决方案转化成模式，最终融会成这本“内功心法”。在仔细研读、用心揣摩本书之后，希望它能够帮助你应对任何一种企业应用平台，驾御任何一种企业应用技术—无论是现在的技术还是未来的技术。
熟悉Fowler的读者都知道，这位大师的写作风格可谓是“深入浅出，娓娓道来”。本书也是一样。前8章是关于企业应用的背景知识，如分层架构、Web表现、业务逻辑、数据库映射、并发、会话、分布策略，等等。在此基础上，随后的各章分别对与这些背景知识相关的设计模式进行了详细的介绍。与其他设计模式的书一样，本书从模式的使用场景、解决方案、UML表示等方面予以介绍，详略有致。就连示例的编程语言的选取—Java和C#—也是与他的写作风格一脉相承的。
夜已深，窗外依旧是绵绵不断的早春小雨。让我们酌一杯清茶，一起来品味大师的话，一起来品味“源于实践、指导实践”的苦涩与甘甜—
“模式的关键点是它们源于实践。必须观察人们的工作过程，发现其中好的设计，并找出‘这些解决方案的核心’。这不是一个简单的过程，但是一旦发现了某个模式，它将是非常有价值的。对于我来说，价值之一是能够撰写这样一本参考书。你不必通读本书的全部内容，也不必通读任何一本有关模式的书。只需要了解到这些模式都是干什么的、它们解决什么问题、它们是如何解决问题的，就足够了。这样，一旦你碰到类似问题，就可以从书中找出相应的模式。那时，你再深入了解相应的模式也为时不晚。”
本书翻译初稿的过程中得到了丁博、王树凤、朱锐、林繁、托明福的大力帮助。王怀民、周斌分别统审了全书。非常感谢UMLChina潘加宇、蒋芳在校对过程中的宝贵意见和建议。
译 者
2004年3月27日于长沙
评论交流
共有97人开贴评论 160人参与评论 85人参与打分 查看
评价等级：
发表于：2005-5-17 23:56:00
在论坛中看了很多人都在推荐这本书，另外经常收到china-pub寄来的推荐邮件也含有这本书的介绍．有意思的是，bbs上和人讨论分布式系统和集中式系统的优缺点的时候，就有人搬出这本书来说明自己的观点，那还是2004年的事情了．今年年初的时候，专门从china-pub上买了一本，准备仔细研读一下．买来之后，粗粗看了一下，说句实话，觉的真有点疑惑了，为什么这样一本只是介绍基本编程技巧，关注代码级实现的书会受到如此的欢迎？它既没有介绍一个系统的方法论告诉我们来如何分析和解决问题，也没有提供系统的解决方案供我们设计系统时进行参考．只是提供一些分散的代码碎片和编程技巧，来告诉我们一些已知的事情，如并发，分布策略，各种模式等，而这些知识只要做过一些项目，或者认真看过一些大学课本，讲的做的都要比这本书涉及的知识点要广要深．看书的过程中，有时候就在想，说不定买本＜用VB实现CRM系统＞之类的书都要比这本书有价值，至少可以了解到如何搭建一个应用系统，如何从系统的角度去看待软件．这样的收获反而更大一些．还是一位老师对这本书的评价解释了我的疑惑：这本书，如果你看目录，很多名词不了解，可以看看，如果目录里面80%的名词都知道，那么也就just so-so．
)
加载中...| 我要写评论 |
| 查看所有评论交流(共97条) |
