系统架构师-基础到企业应用架构-业务逻辑层

一、上章回顾

       上章我们主要讲述了系统设计规范与原则中的具体原则与规范及如何实现满足规范的设计，我们也讲述了通过分离功能点的方式来实现，而在软件开发过程中的具

体实现方式简单的分为面向过程与面向对象的开发方式，而目前更多的是面向对象的开发设计方式。并且我们也讲述了该如何通过设计手段去分析功能点及设计分离

点，应该如何在设计的过程中分析的角度及如何去满足设计规范与原则。首先我们通过下图来回顾下上章要点：

二、摘要

        本文将已架构的方式去分析分层结构中的业务层的设计，如何写出来内聚度，高耦合的业务逻辑层，并且如何根据我们的项目中的个功能需要去设计业务层。我

们本章将会通过几种可能的业务层的设计模式去分析，并且分析每种设计模式的优点与缺点及每种设计模式的应用场景,并且结合一定的使用实例来讲解，当然这些具体

的内容都是自己在项目中的经验与总结。错误之处，在所难免，本人抱着求真务实的态度，争取写好每一篇文章，错误之处还请大家匹配之处，如果您有好的意见或建

议，可以及时跟我沟通，如果对系统架构中的设计规范与模式不了解，可以点击这里查看上篇文章：系统架构师-基础到企业应用架构-系统设计规范与原则[下篇]

        本章讲解的内容我们先看下图中的几个简单模式：

三、本章大纲

       1、上章回顾。

       2、摘要。

       3、本章大纲。

       4、业务层设计分析。

       5、几种不同的业务设计模式。

       6、本章总结。

       7、系列进度。

       8、下篇预告。

四、业务层设计分析

        本节中将会对业务层的设计进行详细的分析。

        首先、我们知道业务层是一个系统中最核心的部分，业务层是实现系统业务功能的核心逻辑层。业务层我们通常说的BLL(Business Logic Layer)层，现在我们

一般的稍微复杂一些的业务逻辑都是通过分层结构来构建一个应用系统，我想大家在组织业务逻辑功能时大部分的情况下是使用BLL层单独负责相应的业务逻辑来实现

的。有些应用可能业务逻辑层并不复杂，这是我们可以把问题简单化，不用引入一些框架性的东西来提升系统的复杂度，但是有些业务规模较大，并且业务逻辑性较强

时，可能使用好的业务设计模式带来的优越性就显而易见了。 我们大家都知道业务逻辑层主要是用来处理领域模型对象之间的逻辑关系的部分。我们都知道业务层的数

据最终是要保存到数据库中，我们在进行业务层设计时一般是在架构中的分层架构模式中出现的。我们知道分层结构中一般是将领域模型与底层数据访问、表现层等进

行分开组织，这样可以让系统结构上清晰，并且容易降低他们之间的耦合性。

        其次、其实我们的很多操作都是可以在业务层来完成，比如说用户的角色权限，数据验证等一些基本的业务规则。当然这里说明业务层主要负责系统中的业务规

则的实现。这里我们需要知道2个概念，就是对象模型与领域模型：下面我们说下这2者的区别。

         描述对象模型与领域模型的区别。

        最后、业务逻辑层作为分层系统中的中间位置，业务模型是表现层与数据层之间的纽带。当然一般我们在系统设计时，可能我们一般不会把领域模型中的领域实

体作为分层之间的传输信息，因为一般来说领域模型中的实体不但包含实体的数据信息，并且包含实体的行为。可能我们在各层中只会用到实体的数据信息，那么无疑

这时采用领域实体的形式进行传输，那么会增加系统的传输负载。当然这里就会出现我们平时所谓的3层模式中的Model层。当然Model层设计的主要作用就是实体数据

的承载，其中并不包含任何行为。具体的行为通过数据访问层来实现CRUD（DDL中的四个基本操作）的操作。

         目前我们设计的分层结构中的对象模型中并不包含实体的行为。其实这里可以看作是比

较好的设计方式，因为采用对象模型的方式进行数据传输时可以降低系统的耦合。当然我们也可以把领域实体看作是多个对象实体的组合并且包含这些对象实体之间的

关系。所以我们在做系统架构时可能如何权衡就比较重要，具体是使用领域实体进行数据传输还是对象实体主要还是看业务的需要。

五、几种不同的业务设计模式

       首先我们在业务逻辑层设计时，必须首先确定是采用面向过程还是面向对象的模式来设计。 下面我们就将针对开篇介绍的几种模式进行分别介绍，错误之处请大

家批评指出。我们首先来讲解过程式的2类逻辑层的架构模式。

      过程式模式

       1、事务脚本模式

           事务脚本模式是面向过程的模式，那么我们就不会采用面向对象的设计思想。这种模式是将业务代码映射到用户的操作中。简单的理解就是将用户的每个操作

都对应一个方法，那么这个方法就是我们这里讲的事务脚本。 当然这里的“事务”就是指我们平时说的业务流程，“脚本”则是我们说的流程中的相应操作方法。这里

需要注意的是 ,不要认为数据库操作的相应方法也属于脚本中的内容，我们通常还是将数据访问层单独的书写，只不过脚本中调用而已。

           通常，事务脚本模式中都是一系列的逻辑判定或者循环或其他方式，通过一系列的函数调用来实现业务流程的。通常来说一般业务比较单一或者不是很复杂的

系统功能，通过该模式实现起来会比较简单。而且如果业务流程中的变化较为频繁的话不建议使用该模式来做。我们认为，我们对于这类简单的功能，我们没有必要花

费较大的代价去设计领域模型和其他方面的考虑。

          事务脚本模式的一大优势就是很简单，没有开始时的额外代价，它可以很好的进行快速的应用程序开发，一般情况下来说，如果一个项目的时间紧迫，逻辑简

单，并且使用强大的开发工具时，我们可以使用这样的模式来进行，无论是成本还是开发效率上都非常客观。

          我们根据上面的介绍可能认为，事务脚本模式的可重用性不高，并且耦合性太高，适应性并不好，当时我们仍然可以通过我们好的设计来实现代码的重用，

我们可以在进行“脚本”编写时将重用的部分抽象出来，写一个单独的函数，以达到复用的目的。

          事务脚本模式的一个重大缺点就是通过这样的设计很容易造成代码重复，通常来说我们很容易完成一系列的业务功能，但是随着应用程序功能的增加，那么应用

程序代码会变成非常复杂的程序结构，当然我们可以通过重构去环节该模式的这一劣势，当规模达到一定程度时，我们同样没办法去完成重构工作。

          通过上面的讲述，我们对事务脚本模式有了初步的认识，那么下来我们看看我们在进行业务逻辑层设计时的详细使用该模式的步骤及相关准则。

           本图描述了事务脚本模式的设计过程，那么基本上每个系统流程都可以通过这样的流程来完成设计。下面我们就针对一个简单的实例来讲解下

如何通过这样的设计流程来实现系统的功能。

            我们这里以简单的购物流程来讲述。如何下一个订单

            首先、我们先来分析下用例：

             我们知道注册的会员可以通过将产品添加到购物车中，然后通过去付款模块来进入支付系统，完成订单。

            其次、分析出事务。

             一般来说购物的流程是这样的流程。当然这里也不是标准的形式。

            那么我们如何上述的几个步骤的内容，去完成这个事务的流程。