这时采用领域实体的形式进行传输，那么会增加系统的传输负载。当然这里就会出现我们平时所谓的3层模式中的Model层。当然Model层设计的主要作用就是实体数据
的承载，其中并不包含任何行为。具体的行为通过数据访问层来实现CRUD（DDL中的四个基本操作）的操作。
较好的设计方式，因为采用对象模型的方式进行数据传输时可以降低系统的耦合。当然我们也可以把领域实体看作是多个对象实体的组合并且包含这些对象实体之间的
关系。所以我们在做系统架构时可能如何权衡就比较重要，具体是使用领域实体进行数据传输还是对象实体主要还是看业务的需要。
五、几种不同的业务设计模式首先我们在业务逻辑层设计时，必须首先确定是采用面向过程还是面向对象的模式来设计。 下面我们就将针对开篇介绍的几种模式进行分别介绍，错误之处请大
家批评指出。我们首先来讲解过程式的2类逻辑层的架构模式。
过程式模式 1、事务脚本模式事务脚本模式是面向过程的模式，那么我们就不会采用面向对象的设计思想。这种模式是将业务代码映射到用户的操作中。简单的理解就是将用户的每个操作
都对应一个方法，那么这个方法就是我们这里讲的事务脚本。 当然这里的“事务”就是指我们平时说的业务流程，“脚本”则是我们说的流程中的相应操作方法。这里
需要注意的是 ,不要认为数据库操作的相应方法也属于脚本中的内容，我们通常还是将数据访问层单独的书写，只不过脚本中调用而已。
通常，事务脚本模式中都是一系列的逻辑判定或者循环或其他方式，通过一系列的函数调用来实现业务流程的。通常来说一般业务比较单一或者不是很复杂的
系统功能，通过该模式实现起来会比较简单。而且如果业务流程中的变化较为频繁的话不建议使用该模式来做。我们认为，我们对于这类简单的功能，我们没有必要花
费较大的代价去设计领域模型和其他方面的考虑。
事务脚本模式的一大优势就是很简单，没有开始时的额外代价，它可以很好的进行快速的应用程序开发，一般情况下来说，如果一个项目的时间紧迫，逻辑简
单，并且使用强大的开发工具时，我们可以使用这样的模式来进行，无论是成本还是开发效率上都非常客观。
我们根据上面的介绍可能认为，事务脚本模式的可重用性不高，并且耦合性太高，适应性并不好，当时我们仍然可以通过我们好的设计来实现代码的重用，
我们可以在进行“脚本”编写时将重用的部分抽象出来，写一个单独的函数，以达到复用的目的。
事务脚本模式的一个重大缺点就是通过这样的设计很容易造成代码重复，通常来说我们很容易完成一系列的业务功能，但是随着应用程序功能的增加，那么应用
程序代码会变成非常复杂的程序结构，当然我们可以通过重构去环节该模式的这一劣势，当规模达到一定程度时，我们同样没办法去完成重构工作。
通过上面的讲述，我们对事务脚本模式有了初步的认识，那么下来我们看看我们在进行业务逻辑层设计时的详细使用该模式的步骤及相关准则。
如何通过这样的设计流程来实现系统的功能。
我们这里以简单的购物流程来讲述。如何下一个订单
首先、我们先来分析下用例：