十年磨一劍--從程序員到架構師

一个.net程序员,一个企业应用的开发者,喜欢系统架构,数据库,领域驱动,面向对象,表现层技术。关注重用的理论和实践。设计原则:简单,快速,适应变化能力强,表现层灵活多变...

博客园 首页 新随笔 联系 订阅 管理
  49 Posts :: 0 Stories :: 721 Comments :: 26 Trackbacks

公告

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

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

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

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

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

业务逻辑同时还包括:

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

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

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

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

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

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

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

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

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

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

...

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

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

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

当然还有现在流行的面向对象分析与设计,即OOAOOD

其实无论是哪种方式,业务逻辑的实现基本上分为一个静态的表示,和动态的行为了。

如请假申请

则是要建立一个请假单的实体(或对象),在建立过程中,可能通过程控其业务规则的实现,如必须填写请假开始和结束日期。

建立的这个请假单,原则上是永远存在于这个系统了(当然是在没删除的情况下),然后只要你看到一个这样的对象或一笔这样的数据,你就能通过这个对象知道当初某某某写了这样的一张请假单,这就是这个请假单实体(或对象)所代表的意义。也即业务逻辑的静态表示。

与之对应的就是动态行为了,通过系统的运行(经常是人与系统的交互),这类逻辑得以隐含实现,如

系统拒绝了一个访问者对于他没有权限的请假单的查看请求。

系统将一张事假超过了20天的请假单送给了总经理审核。

系统授予了总经理在登录之后审核特殊请假单权限的许可。

 

对于这些逻辑的实现,系统一般不会留下痕迹,但它确实做了这部分工作。

  

无论是区分底层架构还是识别各种各样的业务逻辑,一个终级目的--就是为了重用。

只有重用才让我们的工作变得有意义起来。

 

将业务逻辑中关于权限的需求提取出来,提供一个可重用的权限解决方案。

将业务逻辑中的流程部分提取出来,提供一个通用的工作流方案。

将业务逻辑中对于数据的验证提取出来,提供一个通用的验证方案。

将业务逻辑对于多国语言的要求提取出来,提供一个通用的多语言解决方案。

将业务逻辑对于UI的相同或相似要求提取出来,提供一个通用的UI解决方案。

等等。。。

 

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

posted on 2009-11-05 16:35 Kevin Zou 阅读(...) 评论(...) 编辑 收藏