应用架构设计总结
在AF框架的设计基本上稳定下来之后，我们的下一个目标就是要在AF的基础之上构建一个应用开发架构。由于AF仅仅只是一个比较底层的Framework，主要是解决远程调用问题，统一了客户端和服务器端的编程模型。然而AF为了保证足够的灵活性，所以没有在应用架构上做任何特定要求。因此，并不能说采用了AF来做开发就一定是面向对象的应用架构。所以我们还需要在AF之上设计一个满足实际开发需要的应用架构。目标就是要避免以往那种事务脚本方式面向过程的结构，尽可能的采用面向对象设计思想，以降低当程序越来越复杂后的开发和维护成本呈指数级升高的趋势。

不过我们所走的面向对象这条路并不平坦。由于我们的经验也都不是很丰富，所以在这个过程中，的确碰到了很多困惑，也走了不少的弯路，并且碰到了很多的阻力，所幸的是大家能团结一致，在技术方向性的问题上能最终达成共识，最后终于咬着牙挺过来了，没有走回面向过程的老路。

许多时候，在以前的开发过程中，许多根本就不是问题的事情。如果采用面向对象的思维来考虑，就变成了一个很困难问题。面向对象业务设计的技术应用范围其实很窄，仅仅只有领域模型可以用到面向对象业务建模的好处。但是为了在领域模型应用面向对象技术，你就要解决比如数据的持久化，界面，远程访问等问题。其实面向对象技术虽然解决了从前面向过程的许多老问题，但是实际上又带来了一些新问题。但是也不能说面向对象技术相对面向过程并没有多少进步，其实这个道理有点像计算机的硬件升级，在当初32位元的386CPU刚出来的时候，相比16位元的286强了n倍，但是当你打算采用386来开发应用的时候，你会发现各种驱动程序都是16位元的，无法很好的兼容。这时候，你要么选择就在286上开发，等待各种条件都好起来了再来转换到32位的。要么就攻克各种困难，领先竞争对手推出一个适应下一代计算纪元，能充分发挥32位平台优势的应用软件。对于我们目前的状况来说，我们没有任何市场优势，但同时也没有老产品的升级包袱，如果我们选择了前者，首先我们推出的产品很难在市场上有任何竞争优势，而且以后必然会面临更痛苦的转型包袱。所以我们只有选择后者。

现在回想起来，在这个攻克的过程中，我的感觉就好象是让一群人一起翻越一座很陡峭的山崖，你必须让每一个人都能够翻越过去。只要任何一个人没有翻越过去，你就只有继续在山下徘徊。幸运的是，相比其它的许多开发团队，我们比较年轻，虽然经验不足，但是同时也能让我们更容易接受新思想和抛弃旧思维。

即便如此，但是也有很多次差点掉进了悬崖。比如我们内部也有过关于“贫血模型”的争论，Martin Fowler很明确的说过：“By pulling all the behavior out into services, however, you essentially end up with Transaction Scripts, and thus lose the advantages that the domain model can bring.”。但由于受到面向过程思维的影响，我们其实也更习惯于接受这种只有getter和setter方法的贫血对象。但是在仔细考虑之后，采用这种方式，最终我们会走回事务脚本的老路。为了从本质上得到提高，即便转换思维的过程很艰难，可能会碰到更多的困难，但是我们也坚决抛弃了“贫血模型”。

现在我们的应用架构基本上是稳定下来了，经过一些波折和走了不少弯路，但是我觉得这个过程和代价是非常值得的，我们一旦翻越了这座大山，在技术上就已经把很多人甩在了后面。毕竟我们相对原来的技术平台真正的是上了一个台阶。不过全部过程还没结束，在以后更复杂的业务中，我们还需要去验证并完善我们的设计。并真正在实际应用中大幅度降低企业软件的开发和维护成本。这才是我们的最终目的。







posted on 2006年6月4日 10:15 由 卢彦
Comments
# re: 应用架构设计总结
2006年6月5日 13:53 by 天堂
但是作为SOA的Service本质上也是贫血。
虽然AF的所谓Service可以提供公共属性和事件，但是和SOA的合同模型还是有很大不一致。
# re: 应用架构设计总结
2006年6月5日 15:28 by 卢彦
虽然SOA的Service贫血，但是并不代表SOA的目前的Service就是最理想的状态。这是由于SOA需要兼容异构系统所做出的妥协，毕竟还有许多老系统根本就没有对象的概念。
设计新的面向对象的系统不能把SOA搬出来作为最佳设计指导。内部的通信接口也没有必要完全兼容SOA的标准。所以AF对SOA的支持也不是简单的把外观SERVICE当作SOA的接口。
# 应用架构设计总结
2006年6月6日 23:48 by sky
在AF框架的设计基本上稳定下来之后，我们的下一个目标就是要在AF的基础之上构建一个应用开发架构。由于AF仅仅只是一个比较底层的Framework，主要是解决远程调用问题，统一了客户端和服务器端的编程模型。然而AF为了保证足够的灵活性，所以没有在应用架构上做任何特定要求。因此，并不能说采用了AF来做开发就一定是面向对象的应用架构。所以我们还需要在AF之上设计一个满足实际开发需要的应用架构。目标就是要避免以往那种事务脚本方式面向过程的结构，尽可能的采用面向对象设计思想，以降低当程序越来越复杂后的开发和维护成本呈指数级升高的趋势。...
# 面向对象系统设计经验谈
2006年6月6日 23:48 by sky
就像我在应用架构设计总结这篇BLOG中提到的那样，面向对象的系统设计就好象一群人翻越一座陡峭的悬崖，只要任何一个人没有翻越过去，那么就无法设计出真正的面向对象系统。
归结一下，在你打算进行面向对象的系统之前，你一定要考虑是否已经解决或能解决以下的问题：...
# 面向对象系统设计经验谈
2006年6月6日 23:50 by sky
就像我在应用架构设计总结这篇BLOG中提到的那样，面向对象的系统设计就好象一群人翻越一座陡峭的悬崖，只要任何一个人没有翻越过去，那么就无法设计出真正的面向对象系统。
归结一下，在你打算进行面向对象的系统之前，你一定要考虑是否已经解决或能解决以下的问题：...