规则引擎是嵌入应用程序的一种组件，我们也一直想引入来解决复杂多变的规则变化，而规则应属某项功能，比如我们在p2p行业，想筛选出种子用户，可能会有很多的条件限制，如投资额达到多少，投资的频率等等，而这些条件又会经常变化，于是用规则引擎抽离出来，从这个角度看规则引擎应该是面向功能拆分（筛选种子用户是属于一项功能）。不过我觉得规则引擎还可以编排流程，比如有A，B，C，D四个流程，
1、当满足条件1时走A-->B-->C-->D
2、满足条件2时走A-->B-->D
3、满足条件2时走A-->B-->C
从这个角度来说是不是也可以认为是面向流程拆分，不知道理解是否正确？

课后思考及问题
1：拆——不仅仅是许多房二代产生原因，还是所有可扩展性系统架构的精髓。
在看正文之前我稍微想了一下，发现能做到水平扩展的，比如：web服务、微服务、数据存储服务等，加上一些机器就能一起扛量，都是流量的路由和中转，对应的服务够纯粹，可以独立提供对于的服务。
2：系统拆分的模式？
2-1：面向流程——分层架构，数据流程非业务流程
2-2：面向服务——微服务，倾向于站在外部视角而言
2-3：面向功能——微内核，倾向于站在内部视角而言
3：规则引擎是常用的一种支持可扩展的方式，按照今天的分析，它属于哪一类？
规则引擎没具体弄过，不过我感觉类似状态转换，是一个功能型的东东。也可通过排除法比较清晰的，看出它应该属于面向功能的类型。

服务是个逻辑概念，功能实现了服务。每个服务（功能）的执行都有一定的流程。如:

public interface LoginService{
    void login();
}

public class PhoneLoginService implements LoginService{
    @Override
    public void login(){
        //1. 流程1
        doA();
        //2. 流程2
        doB();
        //......

    }
}

规则引擎由推理引擎发展而来，是一种嵌入在应用程序中的组件，实现了将业务决策从应用程序代码中分离出来，并使用预定义的语义模块编写业务决策。接受数据输入，解释业务规则，并根据业务规则做出业务决策。它最大的价值是实现了业务决策和应用的分离，也就是说最开始应用和规则是耦合在一起的，随着业务的发展规则越来越多，代码越来越难维护，迫切需要将规则分离出去，规则引擎应运而生，变成了应用的决策支持层。从这一点上来讲它属于流程的扩展性。
        由于大数据和人工智能的发展，决策层的
功能也变得越来越强大和丰富，往往又引入了基于大数据和人工智能的决策方式，规则引擎是其中之一。从这一点上来讲它属于功能的扩展。
        规则引擎是通用的能力，离开了具体的应用就不会产生价值，通常要应用传递参数才能给出决策。从这一点上看它不属于服务的扩展。