个人认为这条路简单，这是一条经验加悟性之路，看太多书籍反而将简单的事情搞复杂，产生误导作用，因为书籍作者都有侧重和当时的局限性（否则不会有时间写书）。
作为一个架构师必须要有两个基本方面知识或功底：模式框架等架构知识 + 业务建模方法（Evans DDD）。但你有一天意识到这两方面区别，以及感觉可以从两方面开始设计新项目，那么你已经入了架构师的门。剩余就是项目经验积累和总结；如果能够掌握性能设计技巧和经验，那么，说明你进入架构师中级，可以独立承担中型项目的前期设计和过程设计的质量把关。
要掌握架构+建模两个基本知识，GOF设计模式又是基础中之基础，掌握GoF模式对架构和建模都有帮助。
GoF设计模式的掌握必须依靠简单原文定义，在实践中使用体会，任何游离于实践的外表式讨论都不能帮助你掌握其精髓。
不是配置文件多的原因，这只是表象，深层次原因就是你们只注重了架构，忽视了两条腿子中另外一个重要的 业务对象建模，也就是没有掌握Evans DDD。
无论Ruby或Grails还是Spring，这些都是技术平台，只是舞台，舞台上唱什么戏剧，戏剧就是业务建模；技术平台是水；业务建模是鱼，可以想见，你的水就是再好，水处理很先进，里面没有鱼，一切都是白搭。这就是造成你项目乱套的深层次原因。
非常同意，关键就是将两者融合在具体软件过程中，这个就体现真正意义上的架构师水平的不同，这其中需要相当经验；当然，这其中需要业务建模专家的帮助，因为在业务建模这个方面，再好的架构师，他对业务的精通可能比不上资深业务专家，但是资深业务专家和业务建模专家又有一定区别，资深业务专家需要掌握一些方法和架构知识才能成为真正的业务建模专家。
当然，如果架构师又是资深业务专家当然是最好的了，可是这样人很少很少，我个人认为：架构师年轻人做比较好一些，因为他们对新技术新架构敏感，敢于使用，但是年轻人分析问题会有失偏颇，因为阅历问题不会全面；而年长一点的程序员，则对业务认识全面，世界观和方法论都比较成熟，所以，分析需求则相对能全面，看得远一些，当然，他们对新架构可能不是那么敏感，因为稳定成熟可能对于他们来说更重要些。
所以，回到楼主这个案例，这个案例使用的架构还是比较新的，而且这也比较容易做到，高薪招几个比较牛的年轻人马上就能办到，但是业务架构的提升则不是花钱就能买来的，所以，国内很多项目在业务架构上相对比较弱。
当然，现在商业公司提出ERP、BPM或工作流等等，这些业务架构是从众多应用中抽象出来，试图达到四海之内皆准的目标，这其实就又范了想做相对论公式那样的妄想，世界那么复杂纷繁，每个公司有自己特点，怎么可能在数学上做的那么完美，用几个通用业务架构就能够搞定，所以，ERP BPM或工作流这样的业务重用架构粒度还是太大，还是必须根据每个公司使用Evans DDD这样实事求是的方法论来具体问题具体研究，而且有可能开发效率更快，不会比你使用什么大公司BPM软件慢，别看那些软件画画图就能解决问题，关键是图如何画出来的，这个背后存在哲学思考和方法论，打个比喻，股票图走出来你知道前面是底或顶，但是之前你能够知道吗？这个简单哲学道理很多无知无畏的人都体会不了，真是中国教育的失败。