顿悟, 软件的设计

题目倍儿牛B，进来看了，符合楼主工作四年的领悟，共勉，呵呵

对软件的思考
作为一个软件开发人员, 我, 工作了四年, 入行时间不长, 一直在JAVA领域做项目, 从JSP时代走过, 做过EJB项目, 维护过用procedure写的业务逻辑, 参与了银行系统(比较规范)的开发, 作过系统的售前方案,现在暂作项目管理, 虽然,每个项目都有它特有的行业背景和时代特征, 从一个程序员的角度去看这些项目, 无非让程序员实现起来感觉烦燥或困惑与否, 因为初级程序员的水平来没有这样的感悟能力, 所以, 部分人会选择继续学习, 学习语言的特性, 学习设计(模式), 学习项目架构, 学习操作系统, 学习业务知识等等, 正是这些知识的积累, 程序员开始成长, 变得充实而自信,更多的应对和解决实际问题. 但这些是项目的全部吗? 是否具备了这些知识, 就达到了项目架构师或系统分析师的要求? 现在我的回答: NO.

如何理解设计
那么什么是软件设计, 什么是软件的灵魂, 这是首先要回答的问题. 之前, 我的理解如下, 熟练使用几种设计模式, 软件能够灵活适应业务变更, 软件可以灵活配置, 等等. 虽然能达到这样要求的软件已比较接近答案, 但还没有达到真正设计的高度.

我的回答
基于业务模型(domain model)构建, 采用某种语言实现, 结合具体的框架和容器, 为展示层(view, 不一定有)提供
服务的完整解决方案.

domain model: 是对行业的业务建模, 行业的业务高度抽象和涵盖, 所有业务都可以从些引申, 我称之为项目的core, 这是项目的核心, 行业解决方案的核心, 即神.但, 只有些, 也不能称之为一个项目或框架.
语言/框架/容器(架构层): 这是实现手段,对domain model的实现, 即形. 这里涉及到操作系统, 通讯方式, 持久方案, 服务和流程设计,这里往往被是最容易被人们认为的设计部分,而没有一个完整的domain model作支撑, 这样的设计也不会走太远, 至少, 有一定的限制. 但,如果这个的设计能够被完成, 在业内也是一个不错的软件, 也能做到被人称道.
view: 用户接口, 即外衣.

为什么ror/grails不能被应用到企业开发领域, 很大程序上是由于它不能对domain model的支持, 软件的灵活性是复杂应用条件下, 显得无能为力.现在大部分软件也没有domain model, 更甚将技术架构与view混为一谈, 导致需求的变更引导软件整体变更,不能适应需求的变化.
架构层可以由EJB,SPRING,SOA,等实现,这也只是服务的接出方式,适应技术发展的表现.但架构的核心不应因此改变而改变.

适用范围
以上适用于企业应用和服务性网站的设计.

声明:以人为本人现阶段的认识,有不足和错误之处,请拍砖.在此先谢过各位.

好几条路可以走，长短不一；楼主悟出的这条路不算长；
就围绕domainModel来说了？其实就目前世面上的主流软件产品来看，有多少有影响力的软件是有完整的domainModel的？甚至是domainDriven来开发的？我觉得从历史规律来看，目前国内有影响的系统大都是以数据为中心的，即先有数据模型，再有这些数据模型的内存表示（java代码），并且保守地讲，也只能继续按照这个模型来维护（以数据为中心）；我并不觉得它们差，我当然也不会觉得真正拥有domainModel的软件差，它们都是软件，并且都可以很优秀。

如何理解设计？

说什么domain model，什么设计模式，什么样的架构，有用么？现在还说不到那一步上；先要看你在什么行业里面谈设计；不同的行业就有不同的情况；说实话，我看到此文标题之后，我真没有料到会出现这些词汇，并且还说得这么细致。我预想中应该会给大家讲个故事，或者寓言之类的，启迪软件设计智慧的东西，我觉得“顿悟”者应该讲一个这样的东西。

是否“顿悟”？从上面来看，楼主可能还要继续“悟”；而后对ror/grails的一些说法自有人来解释，就不多说了。