了解到《企业应用架构模式》旨在探讨企业应用发展的实践，书中有关于如何开发企业应用的教程和40多种模式，用以解决在创建企业应用过程中可能会遇到的常见问题，并且，书中还包含许多UML图以及Java代码或C#代码示例。通过阅读此书，将能够对企业应用进行分层，获悉组织业务逻辑的主要方法，使用MVC模式来组织Web应用，并且在多事务运行时处理并发数据。结合这学期学习的课程软件设计、软件构造、软件需求与分析、软件开发案例分析，觉得很是贴合，所以决定本学期的第一本书，就是阅读《企业应用架构模式》。
我是带着一些架构问题去看这本书的，但却意外的收获了许多其他的东西。诚如许多书评已经指出的，这本书放在hibernate出现之前，那是相当前卫的。orm之中的许多设计细节问题这本书都说的很清楚。另外，在脚本语言和敏捷盛行的当下，书中的C#、Java例子也略显笨重。在Ruby、Python的冲击下，现在的开发速度越来越快，大家的思维已经和十年前完全不同。更明显的是，现在的应用大多数是网站和移动设备的app。虽然在成书之时作者已经非常有远见的考虑到了它们，但受时代所限，着墨太少。那能从这本书中学到什么呢？首先，会看到架构演进的轨迹。现在我们习以为常的基础设施，它为什么是现在的样子，前人碰过了哪些壁才创造了它们，这是别的地方找不到的。其次，虽然时代在变，但还有些东西没有变，比如一些设计模式在架构上的应用，比如mvc。虽然现在就连大学毕业生都知道有mvc这个东西，但许多人工作若干年之后也不一定理解了mvc的内涵。真正写起代码来，怎么样去设计模型，怎么样去分层，哪些东西属于模型，哪些东西属于控制器，哪些东西属于视图，都还会有许多困惑。这本书的翻译没有有些人说的那么糟糕，我觉得还是很不错的。这本书的另一亮点是它的作者Martin Fowler。他写书有个特点，那就是只讲自己的经验。但凡写出来的东西，在平实的语言中你就可以看出，这是他经过自己的思考所得出的东西。
关于架构。软件业的人乐于做这样的事——找一些词汇，并把它们引申到大量微妙而又互相矛盾的含义。其中就包括“架构”（architecture）这个词。我个人对“架构”的感觉是，它是一个让人印象深刻的词，主要用来表示一些非常重要的东西。很多人都试图给“架构”下定义，定义本身却很难统一。能够统一的内容有两点：一点是“最高层次的系统分解”；另一点是“系统中不易改变的决定”。越来越多的人发现：表述一个系统架构的方法不只一种；一个系统中也可能有很多种不同的架构，而且，对于什么在架构上意义重大的看法也会随着系统的生命周期变化。Ralph Johnson经常在邮件列表上发帖，并提出一些令人关注的见解。他认为，架构是一种主观上的东西，是专家级项目开发人员对系统设计的一些可共享的理解。一般地，这种可共享的理解表现为系统中主要的组成部分以及这些组成间的交互关系。它还包括一些决定，开发者们希望这些决定能及早做出，因为在开发者看来它们是难以改变的。架构的主观性也来源于此，如果某些东西并没有那么难以改变，那么它就不再与架构相关。到了最后，架构自然就浓缩成一些重要的东西，不论这些东西是什么。在这些架构模式中，最让人欣赏的就是“层次”，以及这些层次之间如何协同工作。大多数重要的企业应用都是按照某种形式的层次分层设计的；当然，在某些情况下，别的设计方式（如管道方式、过滤器方式等）也有它们自己的价值，而层次是应用最广的设计方式。架构模式表示了企业应用各主要组成部分间的重要决定，设计模式有助于架构的实现。
关于企业应用。编写计算机软件的人很多，我们通常把这些活动都称为软件开发。但是软件的种类是不同的，每种软件都有自身的挑战性和复杂性。企业应用一般都涉及到大量复杂数据，而且必须处理很多“不合逻辑”的业务规则。虽然有些模式是适合所有软件的，但是大多数模式都还只适合某些特定的领域和分支。比如，企业应用包括工资单、患者记录、发货跟踪、成本分析、信誉评估、保险、供应链、记账、客户服务以及外币交易等。企业应用不包括车辆加油、文字处理、电梯控制、化工厂控制器、电话交换机、操作系统、编译器以及电子游戏等。企业应用一般都涉及到持久化数据，数据必须持久化是因为程序的多次运行都需要用到它们——实际上，有些数据需要持久化若干年。在此期间，操作这些数据的程序往往会有很多变化。这些数据的生命周期往往比最初生成它们的那些硬件、操作系统和编译器还要长。在此期间，数据本身的结构一般也会被扩展，使得它在不影响已有信息的基础上，还能表示更多新信息。即使是有根本性的变化发生，或公司安装了一套全新的软件，这些数据也必须被“迁移”到这些全新的应用上。企业应用一般都涉及到大量数据——一个中等规模的系统往往都包含1GB以上的数据，这些数据是以百万条记录的方式存在的。巨大的数据量导致数据的管理成为系统的主要工作。早期的系统使用的是索引文件系统，如IBM的VSAM和ISAM。现代的系统往往采用数据库，绝大多数是关系型数据库。数据库的设计和演化已使其本身成为新的技术领域。企业应用一般还涉及到很多人同时访问数据。对于很多系统来说，人数可能在100人以下，但是对于一些基于Web的系统，人数会呈指数级增长。要确保这些人都能够正确地访问数据，就一定会存在这样或那样的问题。即使人数没有那么多，要确保两个人在同时操作同一数据项时不出现错误，也是存在问题的。事务管理工具可以处理这个问题，但是它通常无法做到对应用开发者透明。企业应用还涉及到大量操作数据的用户界面屏幕。有几百个用户界面是不足为奇的。用户使用频率的差异很大，他们也经常没什么技术背景。因此，为了不同的使用目的，数据需要很多种表现形式。系统一般都有很多批处理过程，当专注于强调用户交互的用例时，这些批处理过程很容易被忽视。企业应用很少独立存在，通常需要与散布在企业周围的其他企业应用集成。这些各式各样的系统是在不同时期，采用不同技术构建的，甚至连协作机制都不同：COBOL数据文件、CORBA系统或是消息系统。企业经常希望能用一种统一的通信技术来集成所有系统。当然，每次这样的集成工作几乎都很难真正实现，所有留下来的就是一个个风格各异的集成环境。当商业用户需要同其业务伙伴进行应用集成时，情况就更糟糕。即使是某个企业统一了集成技术，它们也还是会遇到业务过程中的差异以及数据中概念的不一致性。一个部分可能认为客户是当前签有协议的人；而另外一个部门可能还要将那些以前有合同，但现在已经没有了的人计算在内。再有，一个部门可能只关心产品销售而不关心服务销售。粗看起来，这些问题似乎容易解决，但是，一旦几百个记录中的每个字段都有可能存在着细微差别，问题的规模就会形成不小的挑战。这样，数据就必须被不停地读取、合并、然后写成各种不同语法和语义的格式。再接下来的问题是由“业务逻辑”带来的，当构建一个操作系统时，总是尽可能地使得系统中的各种事物符合逻辑。但是，需要注意的是，并不是所有的企业应用都是大型的，尽管它们可能都为企业提供巨大的价值。很多人认为，由于小型系统的规模不大，可以不用太注意它们，而且在某种程度上，这种观点能够带来一定的成本节约。如果一个小型系统失败了，相对于大型系统的失败，这种失败就不会显得那么起眼了。但是，我认为这种思想没有对小型项目的累积作用给予足够的重视。试想，如果在小型项目上能够进行某些改善措施，那么一旦这些改善措施被成功运用于大型项目，它带来的效果就会非常大。实际上，最好是通过简化架构和过程，将一个大型项目简化成小型项目。
大致阅读之后的感受就是虽然书中讲到的有点过时，东西早已成为工程的标配，但没有人不承认它的先见性，以及关于架构模型的讲解，这足以证明这是一本好书！