对于什么是业务逻辑,每个人都有自己的看法,我就讲讲我自己的想法,欢迎大家讨论。
我想判断某个部分是不是业务逻辑,一个最简单的方法就是与另一个完全不同的系统进行比较,如果该问题在另一个系统中不存在了,则它就是这个系统的业务逻辑,否则就不是。
业务逻辑应该是一个系统区别于另一系统的本质所在。
例如,一个现金报销单的审批程序,不同人员对不同金额的审批权限明显就是属于业务逻辑的范畴,因为请假审批程序则不会有此问题存在。
一张请假单必须注明代理人和代理的事项,便是请假审核程序的业务逻辑。
业务逻辑同时还包括:
请假单必须注明请假人,请假时间,原因,假别等
请假单有四种状态:草稿,审核中,已核准和已拒审
满一年才有年假,五年以内七天,十年以内十天
病假一年最多三十天,超过只能作为事假请
只有草稿状态的请假单才可以删除
事假超过二十天需要总经理批准
只有人事主管才可以查看所有部门的请假资料
部门主管只可以查看本部门的数据
任何系统用户只能看到自己的请假单。
请假单核准后,将数据转入公司的考勤系统
...
像这些业务对象的描述,规则,权限,流程等等都应该属于业务逻辑的范畴。
而与之相对的,则是属于非业务逻辑部分,是所有系统设计时都应该考虑的:
1.如何实现数据访问(以及事务的处理)
2.异常处理
3.日志和追踪如何实现
4.缓存策略的设计
5.对象的动态组装和更新替换
6.以何种UI呈现
7.UI与系统服务如何衔接
8.系统如何分层,各层之间如何衔接
...
上面这些我想是一个系统的基本框架,是系统的底层架构。
因此整个系统分为2个问题域
1.业务逻辑:与系统如何实现无关,例如是C#还是Java,B/S 还是 WinForm,Oracle还是Sql Server。
2.底层架构:与业务逻辑无关,大多与软件实现方式相关。
用户大部分时候比较关心业务逻辑,当然他可能要求要Oracle以及web方式实现。如果是这样,则底层架构的设计会依赖在某一具体平台之上。
很多时候,UI也是有业务逻辑的。
如对于不同类别请假单显示为不同颜色,这其实也属于业务逻辑的一部分。
if(核准)
color = "绿色"
else if(拒审)
color = "红色"
else if(审核中)
color = "蓝色"
else
color = "黑色"
因为当哪天需求发生变更,又多了一种状态(如退回),也要修改此UI程序。
(PS:这里讲的业务逻辑是与基础架构相对应的,和园子里其它朋友划分UI层,业务逻辑层,数据访问层的外延不一致)
识别出了业务逻辑,那设计时应该如何实现这些业务逻辑了。
最传统的方法就是结构化分析与设计了,即SA(Structure Analysis)和SD了
当然还有现在流行的面向对象分析与设计,即OOA和OOD
其实无论是哪种方式,业务逻辑的实现基本上分为一个静态的表示,和动态的行为了。
如请假申请
则是要建立一个请假单的实体(或对象),在建立过程中,可能通过程控其业务规则的实现,如必须填写请假开始和结束日期。
建立的这个请假单,原则上是永远存在于这个系统了(当然是在没删除的情况下),然后只要你看到一个这样的对象或一笔这样的数据,你就能通过这个对象知道当初某某某写了这样的一张请假单,这就是这个请假单实体(或对象)所代表的意义。也即业务逻辑的静态表示。
与之对应的就是动态行为了,通过系统的运行(经常是人与系统的交互),这类逻辑得以隐含实现,如
系统拒绝了一个访问者对于他没有权限的请假单的查看请求。
系统将一张事假超过了20天的请假单送给了总经理审核。
系统授予了总经理在登录之后审核特殊请假单权限的许可。
对于这些逻辑的实现,系统一般不会留下痕迹,但它确实做了这部分工作。
无论是区分底层架构还是识别各种各样的业务逻辑,一个终级目的--就是为了重用。
只有重用才让我们的工作变得有意义起来。
将业务逻辑中关于权限的需求提取出来,提供一个可重用的权限解决方案。
将业务逻辑中的流程部分提取出来,提供一个通用的工作流方案。
将业务逻辑中对于数据的验证提取出来,提供一个通用的验证方案。
将业务逻辑对于多国语言的要求提取出来,提供一个通用的多语言解决方案。
将业务逻辑对于UI的相同或相似要求提取出来,提供一个通用的UI解决方案。
等等。。。
从底层架构到通用的业务逻辑解决方案,这些工作做得越多,具体系统开发时就会做得越少,这其中如何把握平衡,则是系统架构者的能力体现了。