系统架构师谈企业应用架构之业务逻辑层

498)this.width=498;'' onmousewheel = ''javascript:return big(this)'' alt="" src="/uploadfile/201301/12/11122036964.png" />

目前我们设计的分层结构中的对象模型中并不包含实体的行为。其实这里可以看作是比较好的设计方式，因为采用对象模型的方式进行数据传输时可以降低系统的耦合。当然我们也可以把领域实体看作是多个对象实体的组合并且包含这些对象实体之间的关系。所以我们在做系统架构时可能如何权衡就比较重要，具体是使用领域实体进行数据传输还是对象实体主要还是看业务的需要。

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

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

过程式模式

1、事务脚本模式

事务脚本模式是面向过程的模式，那么我们就不会采用面向对象的设计思想。这种模式是将业务代码映射到用户的操作中。简单的理解就是将用户的每个操作都对应一个方法，那么这个方法就是我们这里讲的事务脚本。 当然这里的“事务”就是指我们平时说的业务流程，“脚本”则是我们说的流程中的相应操作方法。这里

需要注意的是 ,不要认为数据库操作的相应方法也属于脚本中的内容，我们通常还是将数据访问层单独的书写，只不过脚本中调用而已。通常，事务脚本模式中都是一系列的逻辑判定或者循环或其他方式，通过一系列的函数调用来实现业务流程的。通常来说一般业务比较单一或者不是很复杂的系统功能，通过该模式实现起来会比较简单。而且如果业务流程中的变化较为频繁的话不建议使用该模式来做。我们认为，我们对于这类简单的功能，我们没有必要花费较大的代价去设计领域模型和其他方面的考虑。事务脚本模式的一大优势就是很简单，没有开始时的额外代价，它可以很好的进行快速的应用程序开发，一般情况下来说，如果一个项目的时间紧迫，逻辑简单，并且使用强大的开发工具时，我们可以使用这样的模式来进行，无论是成本还是开发效率上都非常客观。

我们根据上面的介绍可能认为，事务脚本模式的可重用性不高，并且耦合性太高，适应性并不好，当时我们仍然可以通过我们好的设计来实现代码的重用，我们可以在进行“脚本”编写时将重用的部分抽象出来，写一个单独的函数，以达到复用的目的。事务脚本模式的一个重大缺点就是通过这样的设计很容易造成代码重复，通常来说我们很容易完成一系列的业务功能，但是随着应用程序功能的增加，那么应用程序代码会变成非常复杂的程序结构，当然我们可以通过重构去环节该模式的这一劣势，当规模达到一定程度时，我们同样没办法去完成重构工作。

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

498)this.width=498;'' onmousewheel = ''javascript:return big(this)'' alt="" src="/uploadfile/201301/12/B3122036963.png" />

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

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

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

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

498)this.width=498;'' onmousewheel = ''javascript:return big(this)'' alt="" src="/uploadfile/201301/12/C8122036466.png" />

我们知道注册的会员可以通过将产品添加到购物车中，然后通