系统设计其实很有趣--从业务逻辑谈起

对于什么是业务逻辑，每个人都有自己的看法，我就讲讲我自己的想法，欢迎大家讨论。

我想判断某个部分是不是业务逻辑，一个最简单的方法就是与另一个完全不同的系统进行比较，如果该问题在另一个系统中不存在了，则它就是这个系统的业务逻辑，否则就不是。

业务逻辑应该是一个系统区别于另一系统的本质所在。

例如，一个现金报销单的审批程序，不同人员对不同金额的审批权限明显就是属于业务逻辑的范畴，因为请假审批程序则不会有此问题存在。

一张请假单必须注明代理人和代理的事项，便是请假审核程序的业务逻辑。

业务逻辑同时还包括：

请假单必须注明请假人，请假时间，原因，假别等

请假单有四种状态：草稿，审核中，已核准和已拒审

满一年才有年假，五年以内七天，十年以内十天

病假一年最多三十天，超过只能作为事假请

只有草稿状态的请假单才可以删除

事假超过二十天需要总经理批准

只有人事主管才可以查看所有部门的请假资料

部门主管只可以查看本部门的数据

任何系统用户只能看到自己的请假单。

请假单核准后，将数据转入公司的考勤系统

...

像这些业务对象的描述，规则，权限，流程等等都应该属于业务逻辑的范畴。

而与之相对的，则是属于非业务逻辑部分，是所有系统设计时都应该考虑的：

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解决方案。

等等。。。

 

从底层架构到通用的业务逻辑解决方案，这些工作做得越多，具体系统开发时就会做得越少，这其中如何把握平衡，则是系统架构者的能力体现了。