讨论设计时，专业词汇满天飞，每个人的技术背景、工作经验上的不同都会导致在理解上存在着差异。无论是SEI的定义、OMG UML的定义、还有各路大神的定义，都有从不同视角带来的差异。准备后面关注这些不同定义，摊开来大家一起来讨论。
关于’业务逻辑’, 国内国外争论了很多年了(这篇在07年就说没有清晰的定义)，其中几个比较详细的讨论见附录(一定要看评论)。我总结主要分为两类: 一类是逻辑处理论，一类是数据操作论。
逻辑处理论
先看前者，这一类观点，核心是强调逻辑。 细说业务逻辑中,作者将业务逻辑分别做了狭义和广义的定义，其中狭义定义如下:
业务逻辑就是对数据访问操作的简单的封装 (显然就是第二类观点)
而广义的定义如下:
软件产品由界面/交互与业务逻辑两部分构成。业务逻辑是软件产品的核心，但不与使用者交互。
后面这个广义的定义好有力度，一刀从界面(含交互)切开，一边展现(界面及交互)，另一边就是业务逻辑。不过，这个也与国外一位大牛的定义呼应(What is Business Logic Anyway)，大意为:
一个应用中最为珍贵的核心所在，并不依赖于某个特定应用而存在。
这里面已经是从领域驱动设计的角度来看。界面可以理解为应用的展示层，而业务逻辑是领域模型的核心，代表了应用解决领域问题所应用的流程、公共、算法、决策树、各类方法、查询等。
数据操作论
而数据操作论，特别强调操作数据，以Wiki为代表。先看一下Wiki的定义，略有点中间路线的味道，显然是站在企业应用的角度来定义：
依据现实的业务规则来操作数据。(原文:In computer software, business logic or domain logic is the part of the program that encodes the real-world business rules that determine how data can be created, displayed, stored, and changed.)
还种观点认为需要从”业务"的定义来理解业务逻辑。从需求出发，业务规则(Business Rules)是基本的业务需求，包括业务的管理、运算、以及处理数据等。实现时可以分为应用逻辑(application logic)和领域逻辑(domain logic), 这些都是业务逻辑。其中前者是处理一些非核心逻辑，比如ERP中订单号生成的规则了。后面则是核心的逻辑，比如物料清单转为请购单的处理。
另一个此观点的变形，尝试将业务逻辑与MVC/MVP中的Model关联起来。但实际上MVC/MVP这种本身用于展现(GUI或console)的设计方案在有关业务逻辑的讨论上显得太狭义了。对于一些大型应用而言，MVC/MVP可能仅仅处于其中的展现层。
最后还有一层次上的视角问题。从应用的整体来看，和从单独一个层次的角度来看，所谓的”业务"也是不同的。所以配合广义论，业务逻辑就会变成一个无所不包的概念。那么这个概念本身就变成了内部处理的代名词。业务逻辑这个概念本身起源于企业应用的架构设计，未必能适用于整个软件领域。所以，也有很多工程师从来不谈”业务逻辑”。
总结
曾经有人说过，任何普适的概念，和废话一样。从软件的细节到整体，有着无数不同的视角。顺畅的讨论还是要从确定共同的视角开始。下次再讨论时，如果觉察到关于业务逻辑的理解不同，还是先说清楚，你定义的业务和业务逻辑是什么？
参考：
欢迎一起学习、讨论！
