既然是乱弹，当然就不能全用正理推断，因此文中有文不对题的，思维混乱的都属正常范畴，大家谅解则个。
架构，是一个神秘也是一个普通的词汇。
曾几何时，君不见现在架构师就像雨后春笋似的，忽如一夜春风来，千树万树上面结的都是架构师，不管是招聘的，不管是应聘的，动辄就是资深架构师，高级架构师云云。
有的人说，架构是搞一堆时髦的大家不理解词汇，最好是一堆一堆的英文缩写，网上有的，网上没的，就象华为似的，任你是国内的国外的，没有缩写词词典管叫你寸步难行，然后再弄一大堆理论出来，然后架构就有了。
有的人说，架构是设计出来的，最好是把SOA，ESB，JCA，设计模式，架构模式， 运行模式，分层模式，多N个Layer，弄M个tier，让本来清楚点的不清楚，让不清楚的更不清楚，然后画一系列的图，从大到小逐层细化，看懂大的再看中的，看懂中的再看小的，看懂小的，大的已经忘记了。
有的人说，架构是闯出来的，啥子思想，啥子体系，算个屁，偶就厉害，一阵乱拳打开去，架构自然就出现了。
有的人说，架构是重构出来的，再好的设计，到后面也会变形，如果没有及时的重构，就会走样，从正方形，变成长方形，从长方形变成平行四边形，最后不行了，再重新来过，搞一个新的轮回。
还有许多许多的牛人，说了N多NB的理论，都有各自己的理解，看看都是正确的，就是学不会，弄不懂，抓不实。
总而言之，言而总之，看了许多，学了许多，还是弄不灵清。今天自不量力来乱弹一下我在做Tiny过程的中架构观，供大家无事之时挥挥板砖锻炼一下身体，疏通一下筋骨。
1. 方法论
方法论这个东东，看了的人都觉得比较虚，其实我也一直觉得比较虚，但是在许多次的实践之后，才慢慢对这一点有了比较深刻的理解。没有方法论指导下的架构，实际上就像是没有长眼睛的苍蝇一样，撞到哪里到哪里，最后一般来说，做的东西都是缺少体系性的。有的地方可能很强，有的地方可能又比较弱。有的地方有不足，需要进行补充的时候会发现对现有的有严重的冲突。甚至在后面，连自己的方向也没有了，感觉这样也行，那样也行，实际上却是这样也有问题，那样也有问题。总而言之方法论对于体系性思维及整体性思考是非常重要的。
2.设计原则
设计原则在于你的框架中最优先考虑的原则有哪些，它有可能是具体的功能需求（一定是重要的全局影响性的需求，比如：配置需要统一配置，并且要有配置订阅与发布机制），也可能是非功能需求，但是对于整个框架都有约束及限制作用（比如：减法原则，让程序员会最少的知识，就可以开展工作；比较DYR原则，永远不要做重复的事情），同时保证你的路线是在朝既定的路线图前进。缺少设计原则的架构，在最后，就会表现为特点不清晰，内部矛盾比较严重。
3.范围的确定
作为一个架构或框架来说，包含的内容可大可小，东西可多可少，深度可深可浅，如果没有范围的确定，可能在一个问题上就会变成一个深不见底的坑，再也跑不上来。
4.框架的分解
啥东西只要一上升到框架的级别，一般来说就会复杂许多。框架的构建是一个系统工程，一般来说它不是一个人或几个人可以完全搞得定的。参与的人也各有各的优势与缺点，因此让合适的人做合适的事情就是最好的选择了。因此，要把整个大的系统及框架，分解成小的问题领域，在小的问题领域中，只考虑自己这部分的问题并给出最佳方案。各个小的领域与模块都有好的解决方案并有一个相当不错的实现方案的话，就为后续的框架奠定了深厚的基础。当然，每个小的问题领域都要在接口及扩展性方面有深入分析、论证，在局部要力求最优解，当然，一定要遵守前面说的设计元则。
5.框架的集成
框架的集成方面最后采用集成层最薄的原则进行，也就是说，集成成只管进行不同模块之间的黏合，本身不做具体的业务处理。比如：你提供了一个插件框架，最好插件框架中只做把普通模块代码包装成插件的代码，但是不要参与业务逻辑的处理。这样就即保证高内聚与低耦合，又可以进行多模块协作。
架构，是一个神秘也是一个普通的词汇。
曾几何时，君不见现在架构师就像雨后春笋似的，忽如一夜春风来，千树万树上面结的都是架构师，不管是招聘的，不管是应聘的，动辄就是资深架构师，高级架构师云云。
有的人说，架构是搞一堆时髦的大家不理解词汇，最好是一堆一堆的英文缩写，网上有的，网上没的，就象华为似的，任你是国内的国外的，没有缩写词词典管叫你寸步难行，然后再弄一大堆理论出来，然后架构就有了。
有的人说，架构是设计出来的，最好是把SOA，ESB，JCA，设计模式，架构模式， 运行模式，分层模式，多N个Layer，弄M个tier，让本来清楚点的不清楚，让不清楚的更不清楚，然后画一系列的图，从大到小逐层细化，看懂大的再看中的，看懂中的再看小的，看懂小的，大的已经忘记了。
有的人说，架构是闯出来的，啥子思想，啥子体系，算个屁，偶就厉害，一阵乱拳打开去，架构自然就出现了。
有的人说，架构是重构出来的，再好的设计，到后面也会变形，如果没有及时的重构，就会走样，从正方形，变成长方形，从长方形变成平行四边形，最后不行了，再重新来过，搞一个新的轮回。
还有许多许多的牛人，说了N多NB的理论，都有各自己的理解，看看都是正确的，就是学不会，弄不懂，抓不实。
总而言之，言而总之，看了许多，学了许多，还是弄不灵清。今天自不量力来乱弹一下我在做Tiny过程的中架构观，供大家无事之时挥挥板砖锻炼一下身体，疏通一下筋骨。
1. 方法论
方法论这个东东，看了的人都觉得比较虚，其实我也一直觉得比较虚，但是在许多次的实践之后，才慢慢对这一点有了比较深刻的理解。没有方法论指导下的架构，实际上就像是没有长眼睛的苍蝇一样，撞到哪里到哪里，最后一般来说，做的东西都是缺少体系性的。有的地方可能很强，有的地方可能又比较弱。有的地方有不足，需要进行补充的时候会发现对现有的有严重的冲突。甚至在后面，连自己的方向也没有了，感觉这样也行，那样也行，实际上却是这样也有问题，那样也有问题。总而言之方法论对于体系性思维及整体性思考是非常重要的。
2.设计原则
设计原则在于你的框架中最优先考虑的原则有哪些，它有可能是具体的功能需求（一定是重要的全局影响性的需求，比如：配置需要统一配置，并且要有配置订阅与发布机制），也可能是非功能需求，但是对于整个框架都有约束及限制作用（比如：减法原则，让程序员会最少的知识，就可以开展工作；比较DYR原则，永远不要做重复的事情），同时保证你的路线是在朝既定的路线图前进。缺少设计原则的架构，在最后，就会表现为特点不清晰，内部矛盾比较严重。
3.范围的确定
作为一个架构或框架来说，包含的内容可大可小，东西可多可少，深度可深可浅，如果没有范围的确定，可能在一个问题上就会变成一个深不见底的坑，再也跑不上来。
4.框架的分解
啥东西只要一上升到框架的级别，一般来说就会复杂许多。框架的构建是一个系统工程，一般来说它不是一个人或几个人可以完全搞得定的。参与的人也各有各的优势与缺点，因此让合适的人做合适的事情就是最好的选择了。因此，要把整个大的系统及框架，分解成小的问题领域，在小的问题领域中，只考虑自己这部分的问题并给出最佳方案。各个小的领域与模块都有好的解决方案并有一个相当不错的实现方案的话，就为后续的框架奠定了深厚的基础。当然，每个小的问题领域都要在接口及扩展性方面有深入分析、论证，在局部要力求最优解，当然，一定要遵守前面说的设计元则。
5.框架的集成
框架的集成方面最后采用集成层最薄的原则进行，也就是说，集成成只管进行不同模块之间的黏合，本身不做具体的业务处理。比如：你提供了一个插件框架，最好插件框架中只做把普通模块代码包装成插件的代码，但是不要参与业务逻辑的处理。这样就即保证高内聚与低耦合，又可以进行多模块协作。
那可能有的朋友就要问了，你乱弹了这么多，你在Tiny框架中是怎么做的呢？Tiny框架在构建之初就构想了下面的路线图与设计原则和理念，并在下在趄这个方向前进。
Tiny的路线图
Tiny的设计原则
•约定优于配置
–通过约定减少代码及配置量
•减法原则
–从技术经理、技术骨干到开发人员，工作量范围与内容越来越少
•下级服从上级原则
–开发人员无条件服从技术骨干，技术骨干无条件服从技术经理
•自动组装原则
–复用资产，由框架进行自动组装，避免大量的系统配置
•DRY原则
–让各个软件相关参与者不要做重复的事情
•配置集中原则
•模块化原则
•抽象与实现分离原则
–
与各种开源与商业平台有良好的集成能力
Tiny的设计理念
•使用灵活，可以整个使用它，也可以只用它的一个或几个部分
•学习成本低，上手容易
•核心的稳定性，核心部分使用尽量少的第三方框架及包
•方便的外延性，不影响对第三方框架的使用
•现有资产的可延续性，不管以前有什么软件资产，只要愿意，都可以方便的集成、复用
•易于知识积累，真正做到越用越强
•易于集群与水平扩展，能做到不间断提供服务
