个人觉得在实际开发中要根据具体情况来看的，因为功能越全面它的复杂度就越大，所需要的开发人员能力和技能就会要求更高，付出的成本也就最大。比如做一个还未发展起来的电商网就想 将系统做成像京东那样，直接用京东分模块分布式的框架来开发，那得怎么来组建这个团队？更不用说开发成本了。就算团队有能力做到，也没有那个必要这么去做，因为从成本预算和开发周期等方面来看，得不尝失，更多的可能项目还未完成公司就给拖垮了。
一般来说，一个中小型项目，1到5人左右的开发团队，使用一般的三层结构就可以了，不用去细想框架要分三层还是五层，每个层之间要怎么实现解耦，要用什么设计模式.....因为当今飞速发展的互联网时代，快才是王道，做一个中小型项目能用一周完成的，绝不能拖了一个月还未做完。人工与时间成本才是重点中 的重点，唯有快才能更好的生存下来并壮大。至于扩展功能、接口、分布式、并发、大数据......等等问题，实际上过早考虑太多并不是好事情，有经验的程序员在写这个框架时早已留下扩展方案或思路，而没到这一层次的开发人员你想再多也可能想不明白，还不如先做出来积累一定经验后再慢慢学习，慢慢升级框架。
当然也不是说设计框架时不用考虑高内聚低耦合，而是要根据自己的能力与经验来设计出自己能把控的框架出来。因为框架不是开发出来后就不再变动，它也需要不停的进行升级，将你所学到的新知识新技术融合到框架中，使它的功能更加强大，更加健壮。而对于自己不能把控的框架，在团队协作开发和上生产环境后，你就发现有一大堆的坑等着你去填埋，这种框架只能拿来先练练手，有空再慢慢完善。
框架通过小步快跑，不断的迭代升级来慢慢扩展的，当项目上生产环境后，根据新的需求和所碰到的问题，去不停的调整，最终越来越强大。所有框架都是从1.0版本到2.0、3.0......发展而来，而不是直接跳过最初版本到最终成熟版本。
所以说我们在创建一个框架时，必须根据我们当前个人的技术能力、团队成功技术水平、时间、投入成本、项目现状（规模与需求复杂程度）、以后的发展前景来决定所要开发的框架的最终设计方案。当然也不是说不能一步到位，心有多大世界就有多大，只要个人能力和团队能力配得上，老板资金成本雄厚，时间充足，直接上大项目使用超级框架也完全没有问题。
框架和设计模式
度娘上说：框架、设计模式这两个概念总容易被混淆，其实它们之间还是有区别的。构件通常是代码重用，而设计模式是设计重用，框架则介于两者之间，部分代码重用，部分设计重用，有时分析也可重用。在软件生产中有三种级别的重用：内部重用，即在同一应用中能公共使用的抽象块;代码重用，即将通用模块组合成库或工具集，以便
在多个应用和领域都能使用；应用框架的重用，即为专用领域提供通用的或现成的基础结构，以获得最高级别的重用性。
框架与设计模式虽然相似，但却有着根本的不同。设计模式是对在某种环境中反复出现的问题以及解决该问题的方案的描述，它比框架更抽象；框架可以用代码表示，也能直接执行或复用，而对模式而言只有实例才能用代码表示;设计模式是比框架更小的元素，一个框架中往往含有一个或多个设计模式，框架总是针对某一特定应
用领域，但同一模式却可适用于各种应用。可以说，框架是软件，而设计模式是软件的知识。
框架的主要特点和要求
1、代码模板化
框架一般都有统一的代码风格，同一分层的不同类代码，都是大同小异的模板化结构，方便使用模板工具统一生成，减少大量重复代码的编写。在学习时通常只要理解某一层有代表性的一个类，就等于了解了同一层的其他大部分类结构和功能，容易上手。团队中不同的人员采用类同的调用风格进行编码，很大程度提高了代码的可读性，方便维护与管理。
2、重用
开发框架一般层次清晰，不同开发人员开发时都会根据具体功能放到相同的位置，加上配合相应的开发文档，代码重用会非常高，想要调用什么功能直接进对应的位置去查找相关函数，而不是每个开发人员各自编写一套相同的方法。
3、高内聚（封装）