更多内容，查看官网：www.tinygroup.org
约定优于配置原则-COC
Tiny框架在设计时充分考虑此原则，凡是可以通过一定的约定来大大减少配置或开发量的，一般都会采用。
所以在Tiny框架的扩展、开发、配置过程中，会经常发现一些“潜规则”，如果利用好这些“潜规则”，会起起事半功倍的效果。
不要重复你自己原则-DRY
Tiny框架的构建者对于做重复的事情一向是深恶痛绝的，因此非常不原意开发人员在基于Tiny框架进行开发时出现重复的内容。
为此Tiny框架在设计上做了大量的工作，来避免程序员做违反DRY原则的内容，所以在Tiny框架中，所有的工作内容都是做一次就足够。
减法原则
减法原则是我们自己提出的，意思就是给程序员做减法。
一般来说越到底层的程序员，工作时间越短、技能越弱、经验越少。但是实际工作当中，你会发现越到底层的程序员要做的事情越多，要用的技能也越多。
Tiny构建者认为，这也是现在程序员工作效率低、质量差的重要原因。因此我们认为应该给程序员做减发，越到底层的程序员做的事情要越单一、越简单。
下级服从上级原则
可能有人在笑了，这个也算原则？确实，它就是原则，只不过原来下级服务上级是挂在嘴上的，而Tiny框架则从框架层级做了限制，使得下级必须服务上级。
这两点主要体现在流程及页面实现中，上级经理可以对下级完成的工作内容进行强制性要求实现，不同的是流程是采用显式继承的方式，而页面是隐式继承的方式
自动组装原则
一般的软件开发，整个集成过程都需要人员小心翼翼，要配这个配那个，稍不小心就会有这种那样问题的出现
Tiny框架构建者也常常知道这一点给集成人员带来的困难及给软件开发测试带来的巨大的工作量，因此在整个Tiny框架的构建过程中，都非常注重集成过程的自动组装，要求做到扔进去不用管，由框架自动集成。
模块化原则
Tiny框架构建者深深知道，模块化对于软件开发过程中开发、高度、集成、发布、维护过程中所起的作用及节省或花费的巨大成本。因此提出了业务单元()Business Unit)的概念，使得与模块相关的所有内容都可以放在一起。
单一原则
几乎每个熟悉Tiny框架的人可能会问同一个问题，那就是：为什么Tiny分了这么多的工程？
Tiny框架的构建者也深深的知道这样会增加相当的集成工作，但是这样做的好处是可以把单一原则进行强制性的约束，使得一个模块只解决单一模块应该解决的问题，从而避免不同的问题放在一起解决所导致的胡子眉毛缕不清的问题，同时也避免了不恰当的依赖及模板引用。
集中配置原则
在Tiny构建者多年的工作过程中，被配置的问题所常常困扰，在开发期有许多问题是由于配置不当引起，在测试在发布及升级过程中，也有相当多的问题是由于配置不当引起的。
在Tiny框架我们对配置做了大量的工作，一个是COC方式，如果不配，则采用系统默认的值；一个是集中原则：把需要人工需要配置的内容都集中起来统一配置；一个是对于不需要人工干预的配置，那就集成在Jar包中，作为发布者发布项的一部分。