软件建设需要考虑的重要的两点我觉得是：
1、客户的功能需求以及非功能需求。
2、软件的维护性。
软件的技术架构就是为了满足以上重要的两点而诞生的，同时由于软件的技术架构决定了使用它的开发人员所需的水平以及开发的难易，此时又要尽量做到降低对使用者素质的要求以及开发的门槛，以保证开发的高效性，但这个相对上两点来说更没那么重要。
在做一个框架级或者现在流行的诸如应用支撑平台的东西的时候，此时的客户一般来说是公司的开发人员或其他公司的开发人员，那么首先就要得到他们的功能需求以及非功能需求，但软件开发人员此时作为客户来说同样是不够成熟的，因为也许很多的开发人员已经适应了它现有的开发模式，你让它重新接受一套新的肯定会很容易引起它的抵触情绪，这个和很多的行业客户是一样的，它习惯的做法一旦被你打破，甚至你把它以前的做法都改变了，这个时候得到的只能是客户的不满意，同时需求也不好挖掘，呵呵，觉得这个时候一方面的做法通常是先吸取客户现在的做法，提供它目前做法的实现方式，另一方面向客户灌输现在方式的好处，慢慢的让它接受。
另外一方面而言，对于开发人员最重要的就是开发的高效以及简易性，如果框架让开发人员反倒觉得不如以前的开发高效、简易，那么是很难去说服开发人员接受它的，就拿现在基于JAVA的web框架来说，为什么现在很多的web系统不是基于java而是基于php、asp.net等，就技术来说Java的Web框架不会比他们差吧，但为什么呢？就是基于java的web框架实现web系统不够方便，对开发人员的要求比较高，而且效率也比不过基于php、asp.net，当然，这个另一方面是很多的web应用系统真的非常小而且非常简单，很多都是普通的CRUD操作，想想现在基于Java的web框架，N多都是N层架构体系，在开发一个CRUD操作往往涉及到N个层次代码的编写，即使N多的JAVA人员可能会认为那很简单，因为层次职责清晰，开发起来也挺简单什么的，但我想对这个对比起数据驱动的方式进行开发确实是更为复杂了，而且由于层次很多时候会让开发人员难以理解，这个也许是基于Java的框架需要值得思考的地方的吧，很多人都说microsoft就是会讨好开发人员，但如果要做框架级的东西的话要讨好的就是开发人员呀，客户才是上帝嘛。
其实框架也要看面对什么样的开发人员，而且是要看开发人员是做些什么类型的项目的，如果那个项目对于系统的维护性什么并没有特别的要求，而且又比较简单，基本没什么业务逻辑，需求又相对比较固定、范围小的话，我想对这样的情况而言基于Java的框架真的不那么适合，或许可以做一个简化版的JAVA框架更适合这样的需求，或许就是在做这样的JAVA的框架的时候真的值得思考，考虑这样的实现方式，maybe mda is a good solution，^_^
还是那句话，架构要贴近需求，这个才是重点，框架软件的架构则更需要考虑开发人员的易用性，^_^，此时要对框架所面对的客户(也就是开发人员)的项目进行充分的了解，并了解他们现有的开发模式。
ps：说点实际的，举例现在在JAVA界的主流Web技术架构：MVC+Domain Model(Service Facade+Domain Object)+Persistent Layer，在这样的技术架构中写一个CRUD通常要涉及到非常多，比如编写PO，采用ORM的话还得用工具生成xml，同时编写DAO、Service Facade，在这样情况下的Service Facade其实真的是毫无意义，呵呵，变成了无意义的一个层，而且增加了开发人员的工作，得考虑考虑解决方法，也许基于Domain Model去自动生成DAO、Service Facade是个方法，^_^，大家在这种情况下会怎么做呢？？呵呵，反正我觉得这样的情况下MDA确实是一种不错的解决方法。