前言
记得几个月前，在一次北京博客园俱乐部的活动上，最后一个环节是话题自由讨论。就是提几个话题，然后大家各自加入感兴趣的话题小组，进行自由讨论。当时金色海洋同学提出了一个话题——“什么是业务逻辑”。当时我和大家讨论ASP.NET MVC的相关话题去了，就没能加入“业务逻辑”组的讨论，比较遗憾。
其实，一段时间内，我脑子里对“业务逻辑”的概念也是非常模糊的。但在不断地阅读、思考和实践过程中，这个概念及其相关的内容才在我脑子里渐渐清晰。我想，很多朋友也许也对这个概念不是很了解，所以愿意结合既有资料和自己的思考，总结一篇关于业务逻辑的概述性文章，一则与朋友们分享探讨，二则也是为自己对业务逻辑的学习做一个总结和提升。因为我还不敢说对业务逻辑内涵及外延理解的非常充分，所以文中如有不当之处，还请各位不用客气，尽管批评就好！
内容提要
===================前篇=====================
前言
内容提要
1、我把业务逻辑丢了！——找回丢失的业务逻辑
2、细说业务逻辑
2.1、业务逻辑到底是什么
2.2、业务逻辑的组成结构
2.2.1、领域实体（Domain Entity）
2.2.2、业务规则（Business Rules）
2.2.3、完整性约束（Validation）
2.2.4、业务流程及工作流（Business Processes and Workflows）
2.3、业务逻辑层职责相关争议
2.3.1、争议一：数据的格式化
2.3.2、争议二：数据合法性及完整性验证
2.3.3、争议三：CRUD
2.3.4、争议四：存储过程
===================后篇=====================
3、业务逻辑的架构模式及实现
3.1、Transcaton Script
3.1.1、概述
3.1.2、分析
3.2、Table Module
3.2.1、概述
3.2.2、分析
3.3、Active Record
3.3.1、概述
3.3.2、分析
3.4、Domain Model
3.4.1、概述
3.4.2、分析
3.5、各种架构模式的比较及选择
4、结束语
参考文献
1、我把业务逻辑丢了！——找回丢失的业务逻辑
相信朋友们基本都是软件开发人员。不论身处什么职位，我们的工作都有一个共同的目标——制作软件产品。而所谓的软件产品，一定是在某个领域内去实现某些业务。如此看来，“业务逻辑”本应和“软件产品”是紧紧绑在一起的，没有业务逻辑，何来软件产品？
但是，我发现一个奇怪的现象，一说业务逻辑，很多人就无法形成清晰地印象。例如，经典的三层架构：表示层、业务逻辑层和数据访问层，一提到表示层或数据访问层，大家脑子里马上能产生出清晰的概念，但一提到业务逻辑层，就有点模糊了，或者完全不知道其是什么，或者有个模糊的轮廓，但对其具体的职责、结构不是很清楚。真是奇了怪了！我们天天和业务逻辑打交道，搞不清业务逻辑是什么。
对于这个奇怪的现象，我思前想后，结合自身的教训（我也曾很长时间搞不清业务逻辑），终于弄清楚了其原因——这和我们接触这个概念的途径和认知结构有莫大关系。
不知道有多少人和我一样，首次接触“业务逻辑”这个概念是从分层架构中的“业务逻辑层”概念开始的，我相信不在少数。事情坏就坏在这里！为了让朋友们直观看清“业务逻辑”的概念是怎么被我们丢掉的，请大家看一个图，这个图展示了很多人对“业务逻辑”的认知过程。
图1-1、狭义的认知分解过程
如图1-1所示，我们先接触了分层架构，然后对每个层产生了初步的认识。其中，由于表示层和数据访问层的代码职责清晰明确，基本能正确认识。但是，由于我们接触的分层架构的Demo大多业务极其简单，又基本是CRUD操作集中型的业务。所以，我们脑子中就产生了疑问：这个所谓的业务逻辑层是干什么的？怎么就简单封装了一下数据访问层的操作？这有存在的必要吗？由于有了这种“先入为主”的误导，使得很多朋友脑中将“业务逻辑”和“业务逻辑层”两个概念混淆了，始终想不明白这东西到底是什么，做什么用的。再加上很多朋友所看的、所做的系统都是CRUD操作集中型的，就形成了“业务逻辑貌似就是对数据访问操作的简单封装”这一片面概念。
到底这一概念有没有错呢？其实没错，因为在简单的、CRUD操作集中型软件中，业务逻辑基本就是对数据访问简单的封装。但是，无错不代表全面，这是一种狭义的业务逻辑理解，而且是狭义中的狭义。为什么这么说呢？因为我们不但是在“业务逻辑层”这么一个狭义范围内去理解业务逻辑，而且还是CRUD集中型操作这种“非常瘦”的业务逻辑层范围内去理解，所以，可谓是在狭义的基础上的狭义。
当我们把这么一个“狭义中的狭义业务逻辑”与“业务逻辑”等同起来时，误会、迷茫、困惑、不屑就出现了。这就如同，给你一只温顺的哈巴狗，还是病怏怏的、无精打采的小哈巴狗，而你把这只“病怏怏的小哈巴狗”与“狗”的概念等同起来了。那么你一定就会为有人养狗看家和警察养狗当警犬抓坏人而困惑：这东西这么弱小，我一脚就踩死了，怎么弄用来看家和抓坏人呢？进而可能会产生“狗狗无用论”，“狗狗废品”等观念。当然，在现实中，很少有人只见过小哈巴狗而没见过狼狗等其它狗类，所以，故事中的误会对“狗”一般是不存在的。但在现实中，确实有很多人只见过业务逻辑中的“小哈巴狗”，却没有见过业务逻辑中的“狼狗”、“藏獒”，所以，这种误会在对“业务逻辑”的理解上广泛存在。
那么，广义的情况究竟是怎么样的？请看下图。
图1-2、广义的认知分解过程
（注意！凡是不特别说明，下文中所有“数据”一词都指需要持久化的数据，而不包括内存中的临时数据。请各位留心。）
如图1-2所示，广义的认知分解应该是这样的：软件产品都是在某个领域内实现某些特定业务，所以，软件产品天生应该分解为界面交互部分和业务逻辑部分，其中业务逻辑部分是软件产品的核心，它客观存在于软件产品内部，但是无法对使用者产生直观刺激，因此业务逻辑不能与使用者直接交互。而界面交互部分是业务逻辑与使用者进行交流的接口，使用者通过界面交互部分，与业务进行交流，从而使得软件产品发挥其作用。
而在具体实现系统时，界面交互部分演化成表示层，业务逻辑部分演化成业务逻辑层。所以，可以认为，数据访问层不是软件产品自然演化的直接产物，之所以出现数据访问层，是因为某些产品的业务属于“数据操作集中型”业务，为了实现隔离、复用等目的，架构师从业务逻辑中分离出了频繁使用的数据访问业务，形成了单独的数据访问层。从广义来说，可以认为数据访问隶属于业务逻辑，因为，数据访问操作实际上也是业务逻辑的一部分。
总结一下几个要点：（这几个要中的业务逻辑均指广义业务逻辑）
1）软件产品自然的可分为界面交互部分和业务逻辑部分。
2）从空间结构上看，业务逻辑和数据访问不是并列关系，而是隶属关系——数据访问隶属于业务逻辑。虽然在具体系统实现层面，数据访问层和业务逻辑层是并列存在，但从概念本质层面上分析，两者是隶属关系。
3）从时间结构上看，应该是先有业务逻辑的概念，才有数据访问的概念。业务逻辑衍生自软件本身，数据访问衍生自业务逻辑。
4）因为业务逻辑是软件产品自然的一部分，所以拥有业务逻辑是软件产品的必要条件（读者可以试着举出一个不包含业务逻辑的软件）。但是一个软件可以没有数据访问，如“计算器”、“不带存档的小游戏”等。
利用以上论述要点和认知分解，朋友们可以试试在脑中重新构筑狭义和广义“业务逻辑”的概念。看能不能把我们丢掉的业务逻辑概念找回来。关于业务逻辑更多的细节，将在下文中讨论。
2、细说业务逻辑
2.1、业务逻辑到底是什么
在第一大节里说了那么多，相信各位基本已经形成“业务逻辑”的概念了。如果我在这里再啰嗦什么，我不嫌累各位也要嫌烦了。所以，这里我仅给出两个定义。
广义上的义务逻辑——软件本身固有的一种品性，自然存在于软件产品内部，是软件具有的在某个业务领域内的逻辑，是软件的核心和灵魂。软件产品除界面和交互外的一切都可看作是广义业务逻辑。
狭义上的业务逻辑——等同于分层架构中“业务逻辑层”的职责，是软件中处理与业务相关任务的部分，一般狭义上的业务逻辑不包含数据持久化，而只关注领域内的相关业务。
对于以上两种定义，希望朋友们不要割裂开来看，而 要辩证统一的去看，这样，才能构建一个完整而辩证统一的“业务逻辑”概念。在下文中，将不再明确区分狭义和广义，“业务逻辑”一词将代表两者的辩证统一体。
2.2、业务逻辑的组成结构
业务逻辑作为一个高层次概念，其内在结构也是非常丰富的，下面我们深入其里，去探寻一下业务逻辑都是由哪些更底层的部分构成的。
2.2.1、领域实体（Domain Entity）
通俗的说，领域实体就是这个领域内有哪些东西。例如，银行业领域内有账户、支票、前台营业员等实体；B2C电子商务领域有商品、订单、交易等实体；魔兽世界游戏的领域内有角色、种族、道具、魔法等实体；高等代数领域有矩阵、行列式等实体。
领域实体是某个领域内各种对象的抽象，可以用名词表示（可以是具体名词或抽象名词，甚至动名词，只要其具有名词性），构成了整个业务逻辑的骨骼和静态模型。一般每个领域实体有自己的一些属性和行为。顺便说一句，领域实体的存在时OOA&D的基础。
在具体的软件系统中，领域实体往往会根据架构的不同有不同的映射存在形式。
其中一种叫做Business Object（BO），即业务对象，某些文献称其为“充血实体类”，这种对象完整抽象了领域内的某个实体，封装了此实体相关属性和行为。在面向对象的设计和架构中，这种实体类很常见。
另一种叫做Data Transfer Object（DTO），某些文献称其为“贫血实体类”，其特点是仅有属性，不存在行为。这种实体类主要负责整体性传递数据。另外，与BO不同的是，DTO可以不抽象领域实体的全部属性，而只根据需要抽象一部分。例如，某个“User”实体存在很多属性，但如果某个方法仅需要其联系方式，可以设计一个DTO，仅有id，email，address，phone等就够了。在面向过程的设计和架构中，这种实体设计比较常见。
2.2.2、业务规则（Business Rules）
业务规则就是某个领域内运作的规则，构成了整个业务逻辑的灵魂和动态模型。业务规则作用于领域实体，领域实体遵从业务规则进行运作。
如：在银行领域内，“转账时从A账户扣除相应款项，在B账户添加相应款项，并从A账户扣除相应手续费，并通过某些途径通知A和B账户的户主”就是一条规则。需要注意的是，业务规则比较抽象，并不是需求，需求需要具体且无二义性，而业务规则只是抽象的一种描述，例如，通知户主的途径是什么？电子邮件？电话？短信？并没有具体描述，但在规则中有“通知”这一项，因此不能将业务规则等同于需求。
2.2.3、完整性约束（Validation）
领域实体和业务规则构建了业务逻辑的主体，但在这主体之上，还存在着一个限制，这就是完整性约束。
完整性约束是对业务领域中的数据、规则的强制性规定与约束。这种约束是系统正常运转的保证。
如“账户密码不能为空”，“身份证号必须符合具体格式规定”，“转账流程必须具有原子性，A账户扣钱、B账户存钱、A账户扣除手续费、通知户主四项操作必须要么都做，要么都不做”，都是完整性约束。
2.2.4、业务流程及工作流（Business Processes and Workflows）
有了上述三项，业务逻辑还不能正常工作，因为还没有“启动器”和“过程托管器”。设想我们有了各种实体类，它们有各自的属性和行为，也有定义好的业务规则和完整性约束。现在实体类仅仅具有实现业务规则的能力，但它们如何启动并交互协调完成业务规则呢？因此我们需要有东西去触发和协调实体。
业务流程或工作流是启动及托管协调领域实体完成既定规则的过程。例如，“在线订购”是一个业务流程，它包括“用户登录-选择商品-结算-下订单-付款-确认收货”这一系列流程。各个实体如会员、订单、商品等已经包含了完成在线订购必要的行为，但仍需一个流程，才能真正完成业务。
具体到程序中，业务流程也许通过一个方法来实现，这个方法负责启动并协调各个实体类，完成一个流程。
2.3、业务逻辑层职责及相关争议
2.3.1、数据的格式化
关于数据的格式化应该放在业务层进行还是表示层进行一直存在争议。我个人的意见是这样的：
业务层送给表示层的数据应该具备以下要求。1）返回的数据应该完成了所有必要的业务处理和业务计算。例如，若返回订单信息让表示层展示，会有个必要的数据——订单总额。这个数据需要首先用各个订单项的单价乘以数量，然后加和。那么，这个数据应该在业务层完成计算直接返回，总之不应让表示层进行任何业务处理和计算操作。2）一次性返回所有需要的数据，避免表示层再一个Action里调用多次业务。打个比方，例如订单中有个“客户姓名”，这个数据不保存在订单表中，而是通过外键关联的，那么，业务层应该将“客户姓名”一并取出返回给表示层。总之，避免表示层在一个Action里多次调用业务层。3）不携带任何格式信息，仅仅是结构良好的纯净数据，如DTO形式。因为，数据如何展示，是表示层的职责，如何在业务层中返回了过多格式信息，就会造成表示层的修改困难。例如，我曾听说过所里承接的一个实际项目，开始是使用B/S，当时他们的业务层返回的数据全都附带了html代码。后来，客户嫌B/S响应不够迅速（可能是客户公司的网络条件不好），要求改成C/S，当时全傻眼了，貌似几乎修改了整个业务层。那个项目相当庞大，7个子系统，投入200人开发了1年多，想想修改的难度吧。
2.3.2、数据合法性及完整性验证
一般做系统，都避免不了数据验证。上文曾经提到，完整性约束是业务逻辑的一部分。如此看来，数据验证一般应该放在业务层。但是，实际情况并不尽然。个人认为数据验证的方式，目前没有统一标准，可以根据需要放在表示层或业务层。但是，我个人不提倡在“表示层的服务端”放置过多完整性验证。因为，表示层的职责应该仅仅是接收数据并传递给业务层，不应对数据是否合法负责。过多的数据验证，不但令表示层代码臃肿，而且使得表示层职责变得不明确。
可以在“表示层的服务端”放置一些简单的验证，如空值验证，两次输入密码是否一致等，但业务关系紧密的验证，最好放在业务层。甚至有些验证只能在业务层验证，如“当前用户名不能与已有用户名重复”，这种验证需要访问持久化数据，需要由业务层完成。
这里之所以强调“表示层的服务端”，是因为一般在B/S系统中，都会在JavaScript里加入一些基本的数据验证，如空值检查，格式正则匹配等。这主要是为了减轻服务器负担，将大多数显然包含不合法数据的请求拒绝掉，而不发给服务端验证。当然，因为可能会出现JS被屏蔽或黑客恶意攻击行为，所以，所有验证不论JS中是否验证过，服务端（可能是表示层的服务端部分或业务层）一定要再进行验证。
2.3.3、CRUD
CRUD，即常说的增删改查操作。关于CRUD是否是业务层的职责，一直也是争议不断。因为目前并没有权威的定义，所以这里我斗胆说一下我对这个问题的看法。还请大家批判性阅读。
一说到“增删改查”，大家一定会觉得这理所当然是数据访问层的职责。我认为这个理解是对的，但是只对了一半！之所以这么说，是因为“增删改查”有两个层次含义。
第一个层次，是数据访问层次上的。在这个层次上，“增删改查”只是单纯的数据库操作，“增删改查”可以理解为“插入一条记录，删除一条记录，更新一条记录的信息，获取一条或多条记录”四个操作，其意义和着眼点完全是数据访问层面上的，不带有任何业务成分和业务知觉。这个层面上的CRUD应该属于数据访问层的职责。
第二个层次，是业务逻辑层次上的。在这个层次上，“增删改查”是业务领域内实体的变化以及一系列相关反应，“增删改查”可以理解为“领域内新增一个业务实体，领域内去掉一个业务实体，领域内一个业务实体更新了信息，得到领域内一个或多个业务实体的信息”。
两者最大的不同，是业务层面上的增删改查往往不是单纯的增加减少，还包括实体变化后相关的业务流程。下面举个例子：
“添加一个新的订单”——这是一条典型的“增”操作。在数据访问层面上，它的意义是“在表示订单的数据表里增加一条记录”；而在业务逻辑层面上，它的意义除了“领域内多了一个订单实体”外，还可能包括“根据业务规则判断是否是重复下单，根据金额对下订单客户的等级做相应提升、发送Email和短信通知客户等”。可以看到，业务层面上的“增”可能不仅是简单封装一个简单的插入记录，可能还要去做其他数据访问——提升用户等级，以及做一些非CRUD的业务操作——发送短信通知。
在许多稍微复杂的系统中，业务往往不仅仅是封装了一条数据访问操作，而是还有很多如计算等业务处理，一个业务操作期间可能要多次使用数据访问操作。退一步说，即使某个业务仅仅封装了一条数据访问操作，其意义和层面也是不同的，在数据访问层面，仅仅是多了一条记录，而业务逻辑层面，是领域内多了一个业务实体。也许其本质上都是往数据库插入一条记录，但人类的抽象思维可以将之在不同层面上区分，这也是人类思维层面的一种抽象能力的表现。例如，我们知道太阳升起不过是地球自转使得从背阴面转到了向阳面，但当人们看日出时，很少有人会说“看！我们从背阴面转到向阳面了！”，我们会说“看！日出！”，这就是同一事物的不同层次表现。
2.3.4、存储过程
也许是性能上的诱惑，许多人喜欢在数据库系统中写很复杂的存储过程。这样，许多业务操作就被写到存储过程中去了。我个人建议，除非对性能要求极高，否则最好还是不要用存储过程实现业务。例如，在一般的系统中，某个业务操作可能需要1秒，而是用了存储过程只用0.1秒，看上去存储过程将效率提高了10倍。但对大多数用户来说，1秒和0.1秒的差别并不大，但是这样做的话，业务会变得十分不容易维护。所以，我个人觉得，除非十分必要，还是不要用存储过程实现业务。