读"企业应用架构模式"一书后的反刍

我得承认，虽然我很努力，很想成为一个架构师和系统分析师，我现在仍是一个程序员。每当我在看那些软件工程或方法论方面的，如书名中有“架构”一词的名典时，都有一种偷窥圣经（或禁书）般地阅读快感。同时，也为我所看不懂和无法坚持看下去（如还是这个大牛所著的“企业分析模式”）某些章节而感到心安理得、天经地义。
　　Martin Fowler 这个大牛的口碑一向很好，而企业应用架构模式一书，熊节的书评题目是：以美的名义。我不得不以一种膜拜的姿态对待它，我“详略得当”地阅读了一遍该书，至于略过的原因多半是我现在理解起来很困难，大概花了我一个星期的业余时间，通常是在床头。我首先感到兴奋，象一个处于混沌状态的，朴素的农业起义首领突然得到了一本指导其革命实践的纲领手册。知其然，后知其所以然，近乎道矣。
　　以下记录一些条目和思考，烙印于此：

        1  layer 指逻辑上的分“层”，tier多指物理上的。three layer指表示层、领域层、数据源层。惭愧的是，以前用delphi参与过三层结构的MIS项目，可真正理解其将“业务逻辑”抽离出单独一个层的精微之处，还是在进入j2ee之后。熟语说得好，"手里有把锤子，看什么都是钉子",delphi强大的可视化环境、数据感知控件（.net中同样强大）使程序员很舒服将业务逻辑交织其中，乐此不疲。
　　2  Transaction Script (事务脚本) - 使用过程来组织业务逻辑，每个过程处理来自表现层的单个请求领域模型。现在用得比较多的还是事务脚本，有一重要原因就是很多程序员的思维仍是根深蒂固的面向过程方式，当然如果业务逻辑不复杂，使用它也是完全合理的。

       3   Domain Model (领域模型) - 合并了行为和数据的领域对象模型。通过互联对象的协作来应付极其复杂的业务逻辑，有的对象模拟业务活动中的数据，有的对象负责捕捉业务规则，数据和处理一般整合在一起。衍生出两种，一是简单领域模型，几乎每一个数据库表对应一个领域对象。另一种是复杂领域模型，它与数据库设计不同，使用继承、策略和其他的设计模式。原则上，领域模型与系统其他层间的偶合应达到最小。

　  4   对象关系结构映射 - 书中相当多的篇幅在讲ORM理论，举的例子也很好理解，很容易和项目实践联系起来，以前走过的弯路，每一次重构，从使用Jdbc包装到现在使用开源框架ibatis(hibernate)，历历在目，无一不印证着大师所指。

          Identity Field  标识域 - 将数据库ID域保存到对象中，用来维护一个内存对象与一个数据库行之间的对应关系。

         Foreign Key Mapping 外键映射 - 将对象间的一个关联映射成表间的一个外键引用。

         Dependent Mapping 依赖映射 - 让一个类为一个子类进行数据库映射。规约为子类没有别的所有者，通常使用 lazy load 。

         Embedded Value 嵌入值 - 将一个对象映射到另一个对象的表的多个域中，通常是小的简单值对象，如 Money  和 Range.
         Single Tale Inheritance 单表继承 - 通过一个表来表示类的一个继承层次，表中各列对应继承层次不同类中的所有域。

         Class Table Inheritance 类表继承 - 表示了类的继承层次，每个类都对应一个表。

         Concrete Table Inheritance  具体表继承 -   表示了类的继承层次，层次中每个具体类对应一个表。

我的首选架构  
         应该属于事务脚本，由以下几部分组成：实体（也就是需要持久化的对象，可能就是“贫血的领域对象”）只是原始数据的对象形式，加上一些最简单的操作（只涉及本身数据的简单处理）。DAO负责将数据转化为实体对象（借力Hibernate or ibatis）。业务逻辑放在service里，每个service方法是一个Transaction Script，可能是现在还没有遇见特别复杂剧烈变动的业务逻辑需求，又或者是驾驭不了大师所推崇的Domain Model，我觉得这已经能很好地对付了。
  
后话：古老的面向对象原则教导我们，要把类的状态和行为封装到一起，师法自然，大道至简，而设计模式却使类体系复杂了，这会引起很多人的疑惑。道理是这样的：设计模式是应对“变化”的，它为了满足OO原则中的开闭原则，设计复杂度和易理解度通常成反比，我们要力求找到较佳的平衡点，艺术和现实的平衡点。