首先要明确出于什么目的来写框架，这个框架适用于什么场景，用来做什么的，框架的用户对象是谁，他们会怎么使用，框架由谁维护，以后怎么发展等....
1.对于设计一个框架要先有一个初步的定位，比如它是一个缓存框架、Web MVC框架、IOC框架、ORM/数据访问框架、RPC框架或是一个用于Web开发的全栈式框架。
2.是否要重复造轮子？除非是练手项目，一般我们是有了解决不了问题的时候才会考虑不使用既有的成熟的框架而重复造轮子的，这个时候需要列出新框架主要希望解决什么问题。有关是否应该重复造轮子的话题讨论了很多，我的建议是在把问题列清后进行简单的研究看看是否可以通过扩展现有的框架来解决这个问题。一般而言大部分成熟的框架都有一定的扩展和内部组件的替换能力，可以解决大部分技术问题，但在如下情况下我们可能不得不自己去写一个框架，比如即使通过扩展也无法满足技术需求、安全原因、需要更高的生产力、需要让框架和公司内部的流程更好地进行适配、开源的普适框架无法满足性能需求、二次开发的成本高于重新开发的成本等等。
2.主打轻量级？轻量级是很多人打算自己写一个新框架的原因，但我们要明白，大部分项目在一开始的时候其实都是轻量级的，随着框架的用户越来越多，它必定需要满足各种奇怪的需求，在经过了无数次迭代之后，框架的主线流程就会多很多扩展点、检测点，这样框架势必变得越来越重（从框架的
3.入口到框架的工作结束的方法调用层次越来越多，势必框架也就越来越慢），如果你打算把框架定位于一个轻量级的框架的话，那么在今后的迭代过程中需要进行一些权衡，在心中有坚定的轻量级的理念的同时不断做性能测试来确保框架的轻量，否则随着时间的发展框架可能会越来越重进而偏离了开始的定位。
4.特性？如果你打算写一个框架，并且只有轻量级这一个理由的话，你或许应该再为自己的框架想一些新特性，就像做一个产品一样，如果找不出两个以上的亮点，那么这个产品不太可能成功，比如你的新框架可以是一个零配置的框架，可以是一个前端开发也能用的后端框架。
5.其它？一般来说框架是给程序员使用的，我们要考虑框架使用的频度是怎么样的，这可能决定的框架的性能需求和稳定性需求。还有，需要考虑框架将来怎么发展，是希望走开源路线还是商业路线。当然，这些问题也可以留到框架有一个大致的结构后再去考虑。
6.通过分析现有框架的功能，可以制定出一个新框架要实现的功能列表。
7.通过分析现有框架的问题，总结出新框架需要避免的东西和改善的地方。
8.通过阅读现有框架的源码，帮助自己理清框架的主线流程为总体设计做铺垫（后面总体设计部分会更多谈到）。
9.如果能充分理解现有的框架，那么你就是站在巨人的肩膀上写框架，否则很可能就是在井底造轮子。
注意:
(1):新开发一个框架的好处是没有兼容历史版本的包袱，但是责任也同样重大，因为如果对于一开始的定位或设计工作没有做好的话，将来如果要对格局进行改变就会有巨大的向前兼容的包袱（除非你的框架没有在任何正式项目中使用），兼容意味着框架可能会越来越重，可能会越来越难看，阅读至少一到两个开源实现，做好充分的调研工作可以使你避免犯大错。
(2):假设我们评估了一些主流框架后已经很明确，我们的MVC框架是一个Java平台的、基于Servlet的轻量级的Web MVC框架，主要的理念是约定优于配置，高内聚大于低耦合，提供主流Web MVC框架的大部分功能，并且易用方面有所创新，新特性体包括：
10:起手零配置，总体上约定由于配置，即使需要扩展配置也支持通过代码和配置文件两种方式进行配置。
11:除了Servlet之外不依赖其它类库，支持通过插件方式和诸如Spring等框架进行整合。
12:更优化的项目结构，不需要按照传统的Java Web项目结构那样来分离代码和WEB-INF，视图可以和代码在一起，阅读代码更便利。
13:拦截器和框架本身更紧密，提供Action、Controller和Global三个级别的"拦截器"（或者说过滤器）。
14:丰富的Action的返回值，返回的可以是视图、可以是重定向、可以是文件、可以是字符串、可以是Json数据，可以是Javascript代码等等。
15:支持针对测试环境自动生成测试的视图模型数据，以便前端和后端可以同时开发项目。
16:支持在开发的时候自动生成路由信息、模型绑定、异常处理等配置的信息页面和调试页面，方便开发和调试。
