Domain logic approaches

领域逻辑组织能够分为三种主要的模式：事务脚本(Transaction Script)、领域模型(Domain Model)和表模块(Table Module)

咱们用得最多就是事务脚本方式（像微软的Petshop4.0,不少国内的三层结构代码生成工具生成的系统，并且这种方式不少公司，不少企业级的项目都在用，还有一些框架引导你用这种方式实现)。这种方式最大的特色就是：简单实用。

为何叫事务脚本（Transaction scripts)呢？也就是实现一个功能，就直接写一个过程（方法），系统的业务就是分散在一个个这样的过程里,像早期用ASP作的大部分系统，一些使用存储过程系统等，尤为是使用存储过程系统，全部业务逻辑都写在存储过程里，很明显的事务脚本实现方式。想想，咱们在业务层实现一个业务时，通常就是这么作的，要实现一个什么功能，在脑子里想想，而后找到那个对应的类，而后再定义一个方法，加上一堆参数。就开始写这个方法的实现代码，要是逻辑复杂点，这方法里一堆ifesle，是否是？若是逻辑不复杂，这种实现到没什么问题,也很方便的。并且，有时候，发现一个类里好多方法，并且大部分是public的。有时候仔细看看，这个类已经再也不是按面向对象方式来实现，虽然你用的是OO语言（java,C#,Ruby等），也用了类，接口，继承、多态等技术手段，可是你是否发现系统中对象之间的协做是多么难，甚至你都以为系统都不存或不多有几个对象协做完成一件事情的，有时你会迷惑不少业务层的类是否应该直接定义成静态类就能够了，根本不须要实例化成一个对象。你还发现，有些方法（功能职责）根本不属于这个类或对象的。这样一来一去，类的职责乱了，方法多了，代码也没重构，愈来愈乱，最后头都大了。因此这就是事务脚本的特色，业务不复杂的系统用这样方式很方便，对技术人员要求也不是很高，由于它的实现思惟仍是按过程方式，大部分程序员都习惯性这样，可是一旦业务变化复杂，系统日益不断的变化，这种方式就变得不堪重负了。

领域模型（Domain Model)，你也可称它为业务模型，这种方式是现今在国内外不少大师级人物提倡的实现方式。这种方式最大的好处，它采用是面向对象方式来分析与设计业务逻辑，不少经验不足的人就会反问，难道我用事务脚本方式就没有用面向对象的方式还分析与设计，我系统里面可全是类、继承，接口等，那我请问你，你每一个类职责单一(SRP)么？或者说你把每一个类的职责分配好了没有，就像你会用C#、java、Ruby了，那为什么还会有《设计模式》呢？我想不少人都会沉默一下，其实要把职责分清楚是一件不容易的事，但也不是不可能，这须要丰富面向对象分析与设计及程序设计的经验（不少人以为不需太多编码经验，我我的是很反对的，由于只有对程序设计语言也很熟悉，才直正设计出优秀系统，特别是每种语言在不一样平台、框架仍是有细微的差异的），还要准确理解与把握系统的业务需求，再通过不断迭代，精化才最终得出一个比稳定的业务模型。引伸《重构》的一句话：“任何傻瓜都能写出计算机能够理解的代码，惟有写出人能容易理解的代码才是优秀的程序员” [Fowler 2002]。那是否是：任何了解OO语言的人都会使用类、接口、继承等特性写代码，惟有能写出职责分明，结构清晰的代码才是优秀的面向对象程序员呢？

  “领域模型实现方式，再也不是由一个过程来控制用户某一动做的逻辑，而是由每个对象都承担一部分相关逻辑”[Fowler PoEAA,2003]。也就是说实现一个业务，是相关领域对象的一系列协做与交互的结果，再也不像事务脚本那样直接在一个过程当中。这比如一我的要完成一个动做都是人体各个器官相互合做协调来完成的，何时你见过一个动做，如吃饭，我只要口张开就能够了。

所以，领域模型实现方式，它通常会先进行业务建模，有时候把业务模型也称之为概念模型，咱们在关系数据库理论里有E-R模型，因此有些人也称之为实体模型。其实，业务，概念模型与实体模型仍是有区别的业务模型实际上是现实问题域进行分析或抽象，这与实体差很少。可是业务模型最终要是用OO方式去试，实体模型要映射成关系模型。所以，业务模型在后期迭代与精化时，不得不采用一些OO手段，如对象职责(Responsibility)，角色(Role)，协做(Collaboration)等。并且实体模型则要考虑关系映射，查询优化，数据冗余的问题。若是你用面向对象方式来实现系统，业务层实现方式采用领域模型方式来实现是最好的，由于他直接与OO语言映射，思惟方式与实现方式统一，因此他能够解决很复杂的业务系统，并且还能够获得很好扩展性，维护性与复用性。

我能够具体说明：例如interactiong项目，那个消息发送策略，

以前的实现方式是写了三个方法（SendMail,SendMSM,SendSMS)在一个类里，这一看，显然的事务脚本实现方式，根本没有去抽象与分析当前的领域逻辑，没有用OO方式去分析与设计当前问题，若是那天还要实现一个发送彩信或者去掉发送手机短信的功能，那还修改原来的类，这显示违背对扩展开放对修改关闭的原则(OCP)。这地方明显就是一个策略模式。还有，像发送者，与接收者，消息这些对象都是能够具备行为，由于领域模型是合并了数据与行为的对象模型。像Petshop的model层，就是一个贫血模型，一个实体对象没有任何行为（方法，操做）。现实中确实能够有一个对象没有行为，可是那确定是少数。通常来讲，一个对象确定有数据与行为。

只有行为没有数据类，就叫无状态类(stateless class)

只有数据没有行为，通常用于DTO（数据传输对象[Data Transfer Object]，这在远程调用与分布式调用中常见的一种设计模式）

所以，像这些发送者，接收者，消息这些类是应该具备行为的，像消息解析器，发送器，这些应该是服务类。因此基于领域模型的系统通常系统分红：表现层(Presentation，应用程序层(Application)，领域层(Domain)，基础结构层(Infrastructure)。应用程序层其实比较弱，有时候也能够叫作服务外观（Service Facade)，有时候能够不须要这一层；领域层，就是业务逻辑层，它包括领域对象与领域业务的一些实现，还资源库(Repository)对象，资源库至关于数据访问对象（DAO），主要用于数据访问，增、删、改、查（CRUD）等；基础结构层，能够包括在不少，数据持久化(Data Persistence)、ORM、安全机制(Security)、数据验证(Data Validation)、异常处理(Exception Handle)、日志跟踪(Tracing)，缓存机制（Caching）、IoC、AOP等,不少模切（Cross Cutting)组件均可以在这层提供。这种划分，是一种经典的领域驱动设计划分，不必定严格按此方式。

表模块（Table Module)，我我的认为表模块应该不算是一种业务逻辑实现方式，可是根据Martin Fowler 《PoEAA》一书，把其归类到领域逻辑模式中，它是处理某一数据库（其实只能是关系型数据库）中表与视图全部行的业务逻辑的一个实例。由于表模块其实就一个数据集合（如：ado的RecordSet,ado.net的DataSet中的DataTable或类型化DataSet等之类），它能够当作是一个数据容器，由于他用一个类(如Product)表示数据库中对应表全部数据及行为，咱们知道面向对象模型与关系模型存在差别，一般一个类与一个实体在概念上相对应，也就是一个类对应一个表，一个类的实例，即对象对应表中某一行记录。类与表都是抽象的，集合的概念，像关系数据库中表就一个二维（行、列）的集合，而表模块用一个类直接表示表中全部数据及行为，因此这个类能够不须要实例化，它就至关于一个表(如.net 的DataTable)，这样全部业务操做都直接用表模块方式进行，从这一律念上来讲，它也能够当作是业务逻辑的一种实现方式，其实你们确定能够得出，这种方式在本质上仍是采用事务脚本方式来实现业务逻辑，只是事务脚本方式，常常要求处理一个业务逻辑（如：查找指定ID的Product）就须要用SQL语句从数据库中获取数据，而这种方式先把数据库的全部行加载到表模块(如：DataTable)中，以后处理全部业务都直接与表模块有关(如：查找指定ID的行，CRUD之类的操做),这正是表模块与事务脚本的细微区别以后。

以上几种业务逻辑实现方式在如今企业级应用系统中都比较常见，其实归根到底也就是两种方式：过程化(事务脚本、表模块)与面向对象（领域模型），这以正好体现两种分析与设计问题方法，面向过程方法论与面向对象方法论。至于用那种方式比较好，这没有绝对的答案，仍是那话老话：软件开发中不变是变化；没有最好的，只有最合适的。可是若是你是一个面向对象的忠实粉丝，那么在不少状况，你的第一选择确定是领域模型，即使是业务逻辑简单的系统，你也会选择领域模型。

 

实现方式	优势	缺点	备注
事务脚本	大多数开发者可以理解 适合于业务逻辑简单的系统 当业务简单时，开发速度很快，代码可读性，可维护性也比较好 比较适合于在关系数据库之一构建 当业务逻辑变化复杂或变化太大时，会出现大量重复代码，并且还很难重构，系统可维护，可扩展性不好		像Petshop4.0、国内不少三层架构代码生成工具生成的系统以及现今国内绝大部分企业级系统(本人估计)都采用这种方式
领域模型	1． 采面向对象方法直接对系统的问题域进行分析或建模，领域模型直观地反映现实世界，可以更好用面向对象语言模型转换，是一种纯OO模型 2． 可以解决很复杂的业务逻辑 3． 能够有效地利用面向对象的特性（抽象，封装，继承、多态等）与相关技术（如设计模式，重构等），以提升系统的可扩展性与复用性。	难以学会如何使用领域型，由于领域模型实现业务逻辑时是一系统对象相互协做完成的，这要求丰富OO分析与设计经验以及其余专业技术能力。 要求O/R映射(不过如今已经有一些比较好解决方案，如：Hibernate、Ado.Net Entity Framework，还有一些面向对象数据库：DB4O，不过关系型数据库仍然将是主流) 对开发人员要求高，要求熟练常握OO及相关技术。	如今不少企业级应用项目开始采用此方式，这主要得益于ORM框架不断成熟，以及模式运动，同时一些设计原则也比较好解决相应问题。 请参看参考书目的： 十一、1三、1六、六、二、5   也可参考DCI与Domain Event[1][2]模式
表模块	1． 适合于系统业务较直观，CRUD操做比较集中 2． 若是支持平台中有比较好工具集支持(如：Ado.Net，数据控件之类)，开发速度快，效率高	1．当业务并不是CRUD集中型操做，特别是领域模型和数据库表模型差别较大时，难度很是大，所以不适合业务复杂的系统	在Microsoft .Net平台有不少工具集支持，有时候你甚至不需写一行代码就能够实现CRUD操做