为了将业务规则从界面和数据库中剥离出来，通常的做法是抽象出一个业务逻辑层出来，专门负责对业务逻辑进行处理；一般多采用三层结构，既表现层，业务层和数据层。通常，开发的时候会将这三层耦合在一起，这样导致在用户需求发生变更，需要修改业务逻辑时，会连同表现层和数据层一起重新编译，全部重新发布；
为什么我们不能将业务层和表示层解耦，相对独立于程序之外呢？将负责实现业务逻辑的业务包转化为一个一个的组件，以插件一样的工作方式提供给业务层框架使用，当某个业务逻辑需要发生变化时，只要对该组件进行替换就可以了。最重要的是可以复用以前的资源，用以前的资源搭建项目；
整体框架如下图：
复用资源
业务逻辑独立于程序之外，存在的格式可以是：动态链接库（DLL），可执行程序（EXE）等；也可以说，业务逻辑组件也是软件，软件也可以是业务组件。
对于以前存在的成熟的资源进行复用，资源可以是程序，动态链接库等格式文件，不需要重新编译，拿来就用。例如：如果，有一套十分成熟的权限控制的资源，而在新的项目开发中需要使用到权限，那么，手中的权限控制资源，不需要和新的项目绑定，不需要重新编译，只要将其资源发布到业务逻辑容器中，表示层就可以正确使用了。
组装函数
客户善变的业务需求，常常导致我们会对业务逻辑组件进行修改，这样的重复的工作，只能消磨开发人员的对项目的信心和耐心！那么我们怎么才能减少修改，同时又满足客户的需求呢？我们能不能设想，业务逻辑通过外部配置，业务逻辑的修改，也可以通过修改配置文件完成，这样不是减少了对业务逻辑组件的反复修改吗？
如图：配置一个写数据的业务
可以对配置的业务进行修改，支持图形化的操作。这样对业务逻辑的变更，修改更容易，而且不需要修改存在的业务逻辑组件和客户端。除非是业务逻辑的重构，才会导致业务逻辑组建的重构；
组装函数是为了高度的业务逻辑组件复用。最初的思想是，希望供组装使用的函数，按一定的规则尽量细致得拆分，这样才能达到高速构建系统的目的。
分工的明确
由于业务逻辑层和表示层的彻底解耦，那么，我们可以将项目组成员细致定义为UI开发人员、业务逻辑开发人员、数据处理开发人员、模式设计人员和业务专家。各类人员的可以更专注于自己的研究领域，明晰工作范围，提高开发效率，减轻工作量；
结束语
为了达到复用资源，我们不必去规定符合该容器的特定开发规则，在开发中还是需要发挥我们惯有的睿智，设计和复用符合项目的组件，让快乐注入到开发历程中；
新增链接： Sloth简介（二）
