有了OO、分层、DI、AOP、TDD和Refector，DDD不再是空谈

一晃眼搞了7、8年的企业应用管理和研究，各种技术、思想翻来覆去折腾了很久，最近总算是有点持拨云见目的感觉了，于是放出点大标题和各位论论道。

主要观点其实在一年半前，已经在jdon首发的文章“坚持发扬EJB、Spring的光辉思想，将组件化进行到底！”(可参http://www.jdon.com/jivejdon/thread/31834.html)进行过论述。当时虽然观点比较激烈，然实际上笔者领悟得不够深刻，故有后面一年多的RoR和PHP之实践。随着时间的推移，与各相关方(上级领导、企业领导、用户、开发商主管、设计人员、开发人员、维护人员等等)的更多观点接触，让我逐渐深入领悟了Java和Spring所蕴含的开发哲学和思想，于是又有此文。
(上文刚刚收到blog，由于是老文，不再发布了，仅作为整理收录)

如果说，每种编程语言和技术都有自己的目标和归宿和话，那么简单来说，JavaEE和后来的Spring是为企业应用而生的。他们诞生的基本目标，正是为了解决困扰企业应用多年的各种复杂问题。故而他们能够达到现在的领导地位，并将一直延续下去。

世间各种事业，都应该是“统一规划，分步实施”。放到信息工程来说，就是“自顶向下设计，自底向上实现”。道理谁都明白，可现实当中执行下来，总是要走样。问题就在于，这二者该如何结合？于是实际项目中，企业用户、分析师、设计师、程序员、维护人员总是不欢而散，最后往往各行其事，一盘散乱。上层的总是抱怨下层在“乱搞”，而下层则嘲笑上层只会“空谈”。结果往往是早已扔进档案袋的系统方案和图表，一堆各种公司、各种程序的“系统”，蒙头蒙脑瞎忙的维护人员。

那为什么结合不了？因为大家没有“共同语言”。开初UML跳出来了，分析师讲得头头是道，程序员看得心烦意乱，用户更是云山雾水。于是连MF都有点烦了，干脆推起了RoR。这乍东西一看太理想了。几乎是分析员可以直接实现程序，而程序员也可以直接分析了。可惜世间难有完美的事物，RoR这种过于“霸道”的东西也许还是有问题的。前有foxpro，后有VB、PB，也许是笔者总是心有余悸，对这种过于“完美”的东西还是先放一放吧。

那是不是说，大家真的不可能有“共同语言”？笔者以为，有，但要折衷(又闻到了实用中庸主义的味道了吧)。如题，OO、DI、AOP、TDD和Refector正是当前的解决之道。

OO是根本，可以作为基本的“共同语言”。图表不必要像UML那么复杂，否则最后除了分析师谁都不会看。只需要简单建上模型，标上属性和接口功能，最多连几根线说明相互关系，这样大家都懂(也就是说，这个类是个什么东西，有什么属性，要实现些什么功能)。这种东西既可做系统说明书，也可以给开发人员，甚至生成Doc做维护文档。
大家要说这不是“空谈”吗？要的就是空谈(就好比不识字的老百姓也会谈治国问题)，就是只谈“有什么”和“做什么”，这样才能有共识。但这种“空谈”其实最难最费时，因为要“共识”。有了共识之后就可以下一步了。

下一步是实现。这个阶段，分层、DI、AOP就可以大展本领了。Spring流行那会，大家是言必DI和AOP。可惜风头一过，现在RoR和Seam时尚年代，很多人大概忘了七七八八。其实笔者现在看来，分层、DI和AOP是继OO之后最重要的思想，它们的核心在于“接口和实现分离”。这样一来，就可以把“做什么”和“怎么做”分家，这才是它们的伟大之处。大家天天把“高内聚、低耦合”挂在嘴边，各搞一套，乱七八糟。J2EE太复杂，大家觉得用不上。好不容易Rod推行了用得上的标准方法，大家本可以有“共同语言”了。可惜人之天生的惰性又把我们推回到“一体化”的泥潭，一代代程序员和系统就这么不了了之了。

OO还是要坚持，它是当前信息世界和现实世界实现映射的最好方法。DI和AOP也是要坚持，只有这样才能屏蔽掉具体实现技术疯狂变化的信息世界。坚持OO，我们才能不受数据存储方式变化的困扰；坚持分层、ID、AOP，我们才能明确地分工合作，摆脱系统规模和事务要求变化所带来的烦恼。

最后还有TDD和Refactor，业务在变，系统在变，我们的技术也在变。一定要能测试和重构，要能很好地测试和重构，否则系统必被变化所毁。要想能够很好地测试和重构，如果你的系统没有OO、分层、DI、AOP，大家是否真可以充满底气地回答“能”。在这一个问题上，Java是最令我放心的伙伴，而Spring更总是带来惊喜。

DDD(领域驱动设计)是一个好的设想，而如今像Spring这类的标准化框架则可以把这个设想变为现实。在这个设想里，管理人员、分析师和用户定义模型功能要求，架构师根据要求选择技术方案，不同的程序员(有做dao的、做service的、做view的)根据接口要求实现代码，通过测试后提交。而因为有支持分层、DI、AOP的框架存在(比如说Spring)，布署人员就可以简单地把他们组装在一起。
面对不断的需求变化，分析师仍然只需增加/变动模型和功能接口，测试人员和编程人员按作相应变化即可。
总体设计、分步实施、按需定制、分工合作、无缝组装，这种工业标准化的软件开发方式才是企业应用的答案。而OO、分层、ID、AOP、TDD和Refactor是真正支撑这个开发方式的支柱。以这样的方式，DDD会真正成为现实。


信息发达国家的软件业其实很大程度上已经实践了这种开发方式(想想那些大规模的外包吧)。这些年国内搞Java的，张嘴闭口便是SSH。可惜很多人搞了一些年后，还是“不识庐山真面目”，成天抱怨“好烦”。在这样浮燥的产业环境下，国内大多数企业应用的质量是低劣的。
即使你天天在写Java、天天在用Spring，如果不能够“知其所以然”，那么你的SSH注定是偷工减料的豆腐渣。所以在此劝诸位从事企业应用的同道，好好静下心来，认真思考一下你的应用所面对的各种问题，再好好思考一下OO、DI、AOP、TDD和Refator给你带来的福音。

愿大家的系统质量都能更上一层楼，这样才可变恶性竞争为良性合作，让我国的信息系统发挥更大更好的作用。

评论

5 楼 mellen 2011-10-11  

设计 是把现实中的 系统，通过抽象的 方式 进行模拟化，并进行实现。。注意 我们无论怎么做 是要面对的是一个“系统”，然后 是建设实现这个系统的功能的“另一个系统”，前系统会随时间变化而提示变化，后系统也同样会如此。
  那么设计的真正目的是在于 根据你的系统的本质和特点 ，来运用“适合”的技术，而使用技术前 是 把前系统 设计架构成 后系统。这个设计架构过程，即是需要很好的设计。
设计包括：使用现有的要素（素材-组件）或自建的要素，采用现有的结构（框架，架构）或自建的结构，运用适合的语言 。实现和解决系统的问题。而系统的关键在于：要素、功能、组织、扩展。 那么设计的关键需要不离开这些。 有时候我想设计这样一个架构： 生产者，决定调度者，分析执行者。 所有的要素（组件）由生产者产生，组合。 而决定者负责根据系统需要 让生产者产生那些要素。 而决定者先要让分析者 执行或分别系统的状体，问题，业务，功能 后 再去操作。 这样 把要素，组织，功能分开。

4 楼 netfork 2009-01-03  

感觉我国确实需要“软件工厂”。有时看上去与国外差别似乎不大，其实软件基建方面差距还是巨大的。在痛恨计算机硬件技术落后的时候，想想软件方面的差距还真不亚于硬件。

3 楼 打倒小日本 2009-01-03  

说道最后 感觉说的怎么好像是"软件工厂"？流水线的模式？

2 楼 AaronHu80 2008-12-31  

我觉得有点理想化，现在可能水平还有限，还处在TDD和Refactor的过程中，体会不到这种深层次的哲学和思想。

但是支持楼主的探索，关注中

1 楼 leobluewing 2008-12-31  

分层，封装，强调可变化，越来越隔离的代码，越来越多的模块，越来越羞涩的调用，越来越要求设计师要牛逼。

可惜 大部分公司设计师水平都不到家，DDD就目前来说还是太远了。