前期架构设计太重要了

目前中国象你这样的案例太多了，招标只看钱多钱少，软件质量把关成了空中楼阁，结果一个个大项目成了很多软件公司的实验项目。象楼主这样觉醒更是少之又少。

banq 能否指一条通向架构师的明路，推荐一下几本好书，最近看了下孙卫琴的《面向对象编程》我觉得此书看后，可以打好做程序员的基础，我后来看了阎宏《JAVA与模式》,觉得有些迷糊，又看了《代码大全2》觉得是讲编码基本规范，技巧，优化方法，现在在看结城浩写的《设计模式》感觉通俗易懂，下一步准备看你写的《JAVA实用系统开发》和《领域驱动设计》，虽然你写的书中用的技术有些过时了，但我想思想不会过时。你觉得还有其它好书吗？推荐一下。

有同感, 想施展一下oo都难, 只能自娱自乐了.

>banq 能否指一条通向架构师的明路
个人认为这条路简单，这是一条经验加悟性之路，看太多书籍反而将简单的事情搞复杂，产生误导作用，因为书籍作者都有侧重和当时的局限性（否则不会有时间写书）。

作为一个架构师必须要有两个基本方面知识或功底：模式框架等架构知识 + 业务建模方法（Evans DDD）。但你有一天意识到这两方面区别，以及感觉可以从两方面开始设计新项目，那么你已经入了架构师的门。剩余就是项目经验积累和总结；如果能够掌握性能设计技巧和经验，那么，说明你进入架构师中级，可以独立承担中型项目的前期设计和过程设计的质量把关。

要掌握架构+建模两个基本知识，GOF设计模式又是基础中之基础，掌握GoF模式对架构和建模都有帮助。

GoF设计模式的掌握必须依靠简单原文定义，在实践中使用体会，任何游离于实践的外表式讨论都不能帮助你掌握其精髓。

没有足够的知识和经验的积累,想DDD,会有些困难.只有不断的尝试,不断的犯错误.反反复复,悟性就来了.

我在编码的时候，就在想怎么消除SWITH ,IF ,ELSE，该怎么优化，以前用先设计数据库然后用HIBERNATE插件生成DOMIAN模型有啥不好，从数据库中读出组织结构树太慢（用缓存提高效率？），页面上的查询条件的保存，。。。。。。相信看书+实践+思考，会解开这些谜团的。还有是否应该参加BANQ老师的培训课呢？

现在我们公司用的是tuscany+spring+ibatis+webwork2+dwr+junit4.4(几乎没法进行单元测试，代码乱套了),觉得配置文件实在是多。。。。听说Grails配置文件很少，Grails是未来的王者？

还有个Ruby on Rails...

告诉大家，我那个项目在某领域是中国第一。。。- -！我想终有一天这项目会倒塌

>现在我们公司用的是tuscany+spring+ibatis+webwork2+dwr+junit4.4(几乎没法进行单元测试，代码乱套了),觉得配置文件实在是多

不是配置文件多的原因，这只是表象，深层次原因就是你们只注重了架构，忽视了两条腿子中另外一个重要的 业务对象建模，也就是没有掌握Evans DDD。

无论Ruby或Grails还是Spring，这些都是技术平台，只是舞台，舞台上唱什么戏剧，戏剧就是业务建模；技术平台是水；业务建模是鱼，可以想见，你的水就是再好，水处理很先进，里面没有鱼，一切都是白搭。这就是造成你项目乱套的深层次原因。

- -!技术都是为领域识知服务地!

彭老大，哦，在技术万花筒中最根本的是埃文斯 DDD，谢谢BANQ指点迷津

目前国内这样的案例确实是很典型，很多项目也都有系统架构师这个角色，但大都是名不符实，别说架构和业务建模兼顾了，目前很多系统的架构都表面是多层，可实际上却是两层的，也就是说是多层的tier，两层的layer。大都是在套流行的概念，但真正的实现是面目全非。对于怎么成为一名架构师，除了banq说的两个基本方面知识或功底：模式框架等架构知识 + 业务建模方法（Evans DDD）外，我觉得架构师还必须对软件过程有深刻的理解，能把握项目的过程。技术架构和业务建模可以说是一个系统的横轴和纵轴，加上一个时间轴（软件过程）的话就是一个完整的具有生命运行轨迹的系统了。系统架构师必须对系统的整个生命周期进行多方位的架构。

>技术架构和业务建模可以说是一个系统的横轴和纵轴，加上一个时间轴（软件过程）的话就是一个完整的具有生命运行轨迹的系统了

非常同意，关键就是将两者融合在具体软件过程中，这个就体现真正意义上的架构师水平的不同，这其中需要相当经验；当然，这其中需要业务建模专家的帮助，因为在业务建模这个方面，再好的架构师，他对业务的精通可能比不上资深业务专家，但是资深业务专家和业务建模专家又有一定区别，资深业务专家需要掌握一些方法和架构知识才能成为真正的业务建模专家。

当然，如果架构师又是资深业务专家当然是最好的了，可是这样人很少很少，我个人认为：架构师年轻人做比较好一些，因为他们对新技术新架构敏感，敢于使用，但是年轻人分析问题会有失偏颇，因为阅历问题不会全面；而年长一点的程序员，则对业务认识全面，世界观和方法论都比较成熟，所以，分析需求则相对能全面，看得远一些，当然，他们对新架构可能不是那么敏感，因为稳定成熟可能对于他们来说更重要些。

所以，回到楼主这个案例，这个案例使用的架构还是比较新的，而且这也比较容易做到，高薪招几个比较牛的年轻人马上就能办到，但是业务架构的提升则不是花钱就能买来的，所以，国内很多项目在业务架构上相对比较弱。

当然，现在商业公司提出ERP、BPM或工作流等等，这些业务架构是从众多应用中抽象出来，试图达到四海之内皆准的目标，这其实就又范了想做相对论公式那样的妄想，世界那么复杂纷繁，每个公司有自己特点，怎么可能在数学上做的那么完美，用几个通用业务架构就能够搞定，所以，ERP BPM或工作流这样的业务重用架构粒度还是太大，还是必须根据每个公司使用Evans DDD这样实事求是的方法论来具体问题具体研究，而且有可能开发效率更快，不会比你使用什么大公司BPM软件慢，别看那些软件画画图就能解决问题，关键是图如何画出来的，这个背后存在哲学思考和方法论，打个比喻，股票图走出来你知道前面是底或顶，但是之前你能够知道吗？这个简单哲学道理很多无知无畏的人都体会不了，真是中国教育的失败。