业务逻辑层分成三个部分，如下图：

（图3）

基础：

1. 业务实体由实体集和实体组成，这些来自数据访问逻辑层。

2. 业务规则定义了对业务实体内部关系，以及业务实体间的关系。
   1.业务实体内部关系：（除非只有一个规则，否则）可以采用职责链模式。（这样可以避免过多的条件判断。）
   2.业务实体外部关系：
       2.1 非强制一对多：可以采用职责链模式。（这样可以避免过多的条件判断。）
       2.2 强制一对多：采用observer观察者模式。
       2.3 多对一：可以采用mediator中介者模式。

3. 业务外观把业务实体和业务规则统一起来。

中级：

1. 考虑一个业务规则，其有严格的限制，联系到多个业务对象，同时其关系成网状，例如：一个实体的方法实现必须满足多个实体的状态值，大量的条件判断不可避免。当系统复杂性提高时，网状的关系将不可避免。此时采用以上简单的方法不能满足要求。这时采用扩展有限状态机来实现将可以解决问题。
2. 业务外观层联系实体和规则，当业务的流程性很强时可以采用工作流技术。同时无论是否采用工作流技术，但系统复杂性提高时，应该采用扩展有限状态机来做控制系统。

高级：

1. 业务规则和业务外观的外在本质上是一个控制系统。业务规则实现状态的转换，而业务外观委派状态的行为。
在业务规则层采用传统方法设计，将不可避免得造成如下之一的情况：1. 控制器庞大而条件判断过多； 2. 产生多个控制系统；3. 多态后系统控制系统之间继续关联关系复杂。造成控制系统维护的困难性提高。 而解决方案就是： 有限状态机。作为一个严格的数学模型，其在状态转换的控制上有明显的优势。
2. 业务逻辑的内在本质上只是一个抽象——解决计算方法、约束条件、转换状态三个问题的控制系统的抽象

表现层：

基础：

表现层作为系统用户界面层，有两个工作：1.界面转换控制；2.用户交互数据收集及其完整性与有效性验证。

1. 界面的转换控制： 当系统的转换复杂化后，对转换的控制变的难以接受，系统将出现多个控制器，对系统的行为变的不可把握。因此在这一层可以采用扩展有限状态机来作为控制系统，这样可以保证系统的行为在可控制范围内，同时可以实现分布式协调控制。

2. 用户交互数据收集及其完整性与有效性验证： 用户界面另一个重要工作。对其的验证包括：1. 对数据的有效性如格式，系统可接受范围检查；2. 数据收集的完整性，例如：1.一些数据用户必填；2. 当用户选择某个选项后，另一些数据成为必填。
同时一个系统的界面将是多而复杂，在每个界面中实现将变的复杂而困难， 因此必须通知统一的交互数据控制器＋XML配置文件进行控制。

高级：

表现层为一个交互应用系统，要解决的最大问题保持内核独立于用户接口，解决方法有三种：MVC和PAC。

1. MVC应用较广泛。本质是变更传播机制确保用户接口和模型间的一致性。
2. PAC（Presentation-Abstaction-Control）应用较少，但是它解决了MVC没有解决的问题——怎样有效组织功能内核的不同部分和用户接口间的通信。因而这个模式尤其适用于由几个不同自给子系统组成的系统。本质是利用agent抽象层。