讨论设计时,专业词汇满天飞,每个人的技术背景、工作经验上的不同都会导致在理解上存在着差异。无论是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可能仅仅处于其中的展现层。
最后还有一层次上的视角问题。从应用的整体来看,和从单独一个层次的角度来看,所谓的”业务"也是不同的。所以配合广义论,业务逻辑就会变成一个无所不包的概念。那么这个概念本身就变成了内部处理的代名词。业务逻辑这个概念本身起源于企业应用的架构设计,未必能适用于整个软件领域。所以,也有很多工程师从来不谈”业务逻辑”。
总结
曾经有人说过,任何普适的概念,和废话一样。从软件的细节到整体,有着无数不同的视角。顺畅的讨论还是要从确定共同的视角开始。下次再讨论时,如果觉察到关于业务逻辑的理解不同,还是先说清楚,你定义的业务和业务逻辑是什么?
参考:
What is the heck is business logic anyway?
What’s the difference between application layer and business logic layer? (SO)
欢迎一起学习、讨论!