1.分布式系统第一法则：尽量不要分布。
2.尽可能早地验证框架是否合理，RUP和XP(极限编程)等方法学都强调这种做法，分别叫可执行架构(executable architecture)和
? 垂直切片（vertical slice）.需要注意两点：第一是先要满足业务需求，第二是尽量早。
?
??? 还是拿个事实来说吧。我所在的公司有很多项目组，最近搞一些交流，我有幸看了看公司金融项目组的框架。其实也许不能说是框架，公司自行开发的ide, 此ide里有2部分组成，一部分是页面设计器，能可视化地以类似excel的方式创立一种特定格式的文件(内容是xml)，此xml经过专门的解析器动态生成jsp页面，里面集成了ext。令一部分是工作流引擎及工作流设计器。用此ide设计出的东西，再部署到一套构建于Struts1.x之上的基础框架上。工作过程大体如下：
web请求---xml文档-----经过解析器动态生成jsp(有缓存机制，更新xml才重新解析为jsp)---跳转到此jsp--提交FormBean---Struts1.x Action--BO执行业务逻辑----PO进行sql拼装并执行。
???? 目前此框架或说产品（我是在不知道怎么称呼她）应用在某大型财务公司项目上，可惜很遗憾，项目没有取得成功。据说此项目的经理是最辛苦的一个，但还没有达到预期的效果。但是，大家总结的时候，没有人说失败的原因是框架问题，只说其他问题。目前，我所在的项目组正在考察这个产品或框架，决定是否采用她。我闲暇反编译了她的大部分源码，择重点翻了翻，又拿了个用她做的一个半成品项目看了看。目前，我心里持否定态度，理由主要如下：
???? 第一，我没有见到用她开发成功的项目。
???? 第二，生成最终jsp或说运行时html上，hibernate.cfg.xml文件名，sql语句完全暴露，一览无余。
???? 第三，生成最终jsp或说运行时html上，ext的api语法格式的javascript错综复杂，令人望而生畏。
???? 第四，我们项目特性是需求多变，时刻在变，而且业务复杂，我感觉用她不太合适。
?
??? 我仍在犹豫中...........