零雨其蒙

         这里所谓的企业级应用，就是Martin Fowler的企业应用架构模式中论述的企业级应用。

         在软件工程过去的40年里，虽然没有任何一种方法论能够达到舍我其谁的程度，但是确实在工业界和学术界达成了一些共识：封装，行为优先于数据考虑，依赖于抽象而非具体，迭代开发，领域驱动设计……而OO范型是这些最佳实践的最好集合。

         软件的设计，来自对于问题域的抽象，随着对于需求的理解深入，我们的设计会随之演化。结构化范型中首先设计数据库，我认为过早的对问题域进行了数学抽象，往往那些抽象过于远离问题域，它代表了当时对于问题域的理解。而数据库又属于依赖的最低层，这种不牢靠的抽象必然会造成设计的不稳定，因此从本质上讲，这种方法就是不可靠的。而OO可以直接去模拟业务领域，可以尽可能的去贴近实际。因为实际业务运行良好，那么你所设计的模型也会更容易的运行良好。我发现越是贴近现实领域的建模，其进化性越好。

       问题领域中不仅包含实体，还包含值对象，服务[Evans03]，而数据库建模则往往只强调实体。那么其他有用领域概念就在设计中丢失了。制作大而全的对象是不切实际的，对象属性和行为的确定要来自于业务需求，对象使得添加和减少属性和行为都变得容易。

       把一些行为和数据按照主题加以分类，写到不同文件里，就像我们写文章需要划分段落一样，每个段落表达一个意思，如果想补充表达某个意思，就去相应的段落扩展。而类就是这一个个段落。当某个段落表达了不同的意思，就按不同的意思分解。我想这和单一职责原则是有同构性的。那一个个函数就像一个个句子，面向过程设计将这些句子按照应用分布在应用中，而面向对象设计奖这些句子按主题分布在具有业务语义的类中。

     企业级应用的特点是：复杂和多变。一个复杂的东西在变是最让人痛苦的。于是尽可能要把它分解为小而简单的东西，让每个变化只局限于一个方面。

     某些东西是不容易变化的，比如商业，申请服务，提供/享受服务，结帐，这个大方向是不会变的。商业的一个子集，餐馆，上千年了，基本流程还不是点菜，上菜，买单？菜和帐是千年不变的实体。

     无疑，OO比数据库建模向前又走了一步。

      做了几个大型系统，和一些需求模糊、变化无常的项目，真找不出什么理由，做企业级应用可以不用OO。

     2008年4月10号补充：但是，现实情况却是，很少有项目采用OO范型，人们认为无论什么方法都不可能彻底解决企业应用核心复杂性（即问题域复杂），转而走向干脆不尝试OO。特别是在这个行业混迹多年、并且在学校只学了结构化方法的人。我与几个公司的信息部的人聊天，他们采用的方法都是先设计数据库，然而我用OO为系统添加了一项功能（我们为他们公司开发了系统，然后我去添加新功能），他们对于使用OO表示赞同，觉得是好方法。但是却没有使用。

      2008年4月13号补充：需求调研一个阶段告一段落，回到北京准备考试。在火车上一直跟同学讲领域驱动开发，讲我过去做的两个使用OO开发的项目的感受，并对比之前使用面向过程方法做项目的感觉：

      1 领域驱动设计，越是复杂、变化灵活的项目越要采用贴近领域的对象模型，只有小的项目才可以尽可能简化对象使得测试刚好通过即可。

      2 切忌UI驱动设计。我做的视频监控项目从最初的需求里包含GUI，到后来不要UI，真是惊天动地的大变化。另外一个作业管理的界面我们修改了20多版，而业务还是那点儿业务。UI可以辅助挖掘需求，但是把它作为最后一件事完全可以。

      3 切忌数据库驱动设计。关系数据库以数学为基础，距离现实领域太远，过早陷入其中危害无穷。

      4 面向对象是比面向数据、面向过程更加先进的方法。我说，当做那个作业管理子系统时，我将函数拆分的非常细，每个函数都是单一职责的，但是管理起来很费劲。我举例说，比如你有一堆帮助文档，包含了J2EE的方方面面，为了方便查找，我想你可能会按照主题将他们放在不同的文件里，然后再放到不同的文件夹里。那么这些文件就是类，文件夹就是包。虽然面向过程编程，你可以采用良好的命名规范，并将其放入单独的文件里（比如Delphi的unit，VB的module），但是其封装性和复用性明显要弱于OO。也就是这种最佳实践再向前迈一步就是OO了。

      5 我的感觉是，越是大型、复杂的商业应用越适合采用OO。虽然OO不完美，OO不是银弹，OO也没有REST、SSOA等时髦，也许话题很陈旧，很“入门”，但是，OO在国内应用的现状，就足以反映出，这是个值得探讨的问题。

[Evans03]Eric Evans，2003，领域驱动设计：软件核心复杂性解决之道。