细说软件产品和业务、业务过程(流程)、业务逻辑

image

作为一名程序猿,需要懂产品,不懂产品的程序猿不是好程序猿猴。而业务逻辑是软件产品的支柱,所以,要懂产品,就必须懂业务逻辑。

介绍业务逻辑之前,先介绍下相关的一些概念。

什么叫业务?

从企业的角度来讲,业务是企业运用科学方法和生产工艺生产出可交付用户使用的产品与服务,并以此为企业带来利益的行为。

举例:

对服装企业来说,业务一般是生产服装;对银行企业来说,业务可以是办理贷款;对软件公司来说,业务可以是开发某种类型的软件,比如开发防火墙软件;对医院来说,业务可以是提供医疗服务。

什么叫业务过程?

“业务流程”和“业务过程”是两个经常出现的词,含义相似,但有轻微区别,这里暂且不做区分,都统一叫做业务过程。

  1. 1)业务过程开始于客户需求,终止于客户需求的满足,为客户创造价值。

  2. 2)业务过程是为了产生产品或服务而设计的一系列步骤,一些过程的结果可能是由组织外的客户所接受的产品或服务,称为主要过程;另一些过程的产出不为外部客户所见,但是有效管理所必须的,称为支持过程。

举例:

业务过程,对于服装工厂来说,可以是产出可穿戴衣物的一系列活动;对医院来说,可以是提供医疗服务的一系列活动;对软件公司来说,可以是开发出满足客户需求的软件产品的一系列活动。

软件产品和业务过程

软件产品具有它的特殊性,通常情况下,企业提供的软件产品、服务,主要用于外部组织、用户实现其业务过程。

举例:

假设有两家公司,A公司和B公司。A公司的业务是提供医疗服务;B公司是开发医疗相关的软件。A公司找到B公司说,我需要你们帮忙开发一个系统,实现XXX功能。这时,B公司考虑的不仅是自己的业务过程:产品,设计,测试,开发,运维等怎么配合去做这件事情,而且还要考虑A公司的业务过程:病人挂号,就诊,住院,缴费结算等等。

什么是业务逻辑?

业务逻辑是系统架构中体现核心价值的部分,典型的三层结构模型中(如下图),介于表现层和数据访问层之间。

通俗的讲,业务逻辑就是个“怎么做”的问题,是产品的灵魂,它的关注点主要集中在业务流程的实现,业务规则的定制等与业务过程相关的。

细说业务逻辑

  1. 业务实体
  2. 业务实体完整性约束
  3. 业务流程(业务过程)
  4. 业务规则
业务实体

关键业务相关的动态的概念性对象

比如,电商企业,业务过程中的买家,商品,就是业务实体,软件实现过程中先将其抽象为概念模型(通常用E-R图表示),然后对其建立结构模型,展现在计算机世界中,可能表现为买家表中或商品表中的一条表记录。

实体业务完整性约束(Validation)

业务实体完整性约束简单说就是对业务实体的约束,比如对商品实体,商品编号必须唯一

注:关于业务实体和业务实体完整性约束,可以看下数据库的相关资料,理解会比较深刻一点

业务流程(业务过程)

如果把产品比作一个人,那么这个业务过程就是产品的骨架。产品只有实现了这个流程,用户才能用它来实现业务。

例子:购物网站为例子

购买者登录网站 -> 浏览商品 ->下单 -> 结算 -> 确认收货 -> 评价

例:以学校申请助学金为例子

学生登陆终端 -> 提交申请 -> 班主任审批 -> 分院负责人审批 -> 学工处审批 -> 资领处审批

业务规则

定义1:业务规则是与特定行业中的特定业务功能有关的决策逻辑的表示形式

定义2:业务规则是对业务的某些方面进行定义和约束的声明

例1:以学校申请助学金为例子

“申请助学金的学生必须是贫困生”,这便是一条业务规则,对申请助学金的做了一个前提申明。

那又为何说是决策逻辑呢?程序中,实现经常会这样:

if 学生 is not 平困生

then 拒绝申请

例2:以购物网站为例子

未登录顾客点击购买商品时,提示先登录

例3:以购物网站为例子

买家下单后,通知卖家商品被拍下。

从上面的例子可以看出,业务规则它不会告诉你怎么做,仅是“决策”,告诉你要做什么,而不会告诉你怎么做。比如,上面的贫困生的例子,它不会告诉你怎么申请贫困生,但是会告诉你要去申请贫困生,再如,上面购物网站的例子,它约定说要去通知卖家,但是不会告诉你怎么通知卖家(通过邮件、电话、短信还是其它??)

小知识点:

一般做系统,都避免不了数据验证,完整性约束是业务逻辑的一部分,按理应该放在业务层。但是实际不然,不提倡在“表示层的服务端”放置过多完整性验证。因为,表示层的职责应该仅仅是接收数据并传递给业务层,不应对数据是否合法负责。过多的数据验证,不但令表示层代码臃肿,而且使得表示层职责变得不明确。

可以在“表示层的服务端”放置一些简单的验证,如空值验证,两次输入密码是否一致等,但业务关系紧密的验证,最好放在业务层,甚至有些验证只能在业务层验证,如“当前用户名不能与已有用户名重复”,这种验证需要访问持久化数据,需要由业务层完成。

这里之所以强调“表示层的服务端”,是因为一般在B/S系统中,都会在JavaScript里加入一些基本的数据验证,如空值检查,格式正则匹配 等。这主要是为了减轻服务器负担,将大多数显然包含不合法数据的请求拒绝掉,而不发给服务端验证。当然,因为可能会出现JS被屏蔽或黑客恶意攻击行为,所以,所有验证不论JS中是否验证过,服务端(可能是表示层的服务端部分或业务层)一定要再进行验证。

难题:什么是业务逻辑

业务是指一个实体单元向另一个实体单元提供的服务。
逻辑是指根据已有的信息推出合理的结论的规律。

业务逻辑是指一个实体单元为了向另一个实体单元提供服务,应该具备的规则与流程。

就像你家的规矩–“吃饭前必须洗手”“有客人来要起立”“睡觉前各自说晚安”-就是业务逻辑的生活化实例。

软件系统架构一般分为三个层次

表示层、业务逻辑层和数据访问层:

  • 表示层:负责界面和交互;
  • 业务逻辑层:负责定义业务逻辑(规则、工作流、数据完整性等),接收来自表示层的数据请求,逻辑判断后,向数据访问层提交请求,并传递数据访问结果,业务逻辑层实际上是一个中间件,起着承上启下的重要作用;
  • 数据访问层:负责数据读取。

业务逻辑的内容包括四部分

  • 领域实体:定义了业务中的对象,对象有属性和行为;
  • 业务规则:定义了需要完成一个动作,必须满足的条件;
  • 数据完整性:某些数据不可少;
  • 工作流:定义了领域实体之间的交互关系。

以大毛网购裤子为例

  • 领域实体:大毛、资金账户、订单、裤子、发货单
  • 业务规则:大毛点击购买就会生成订单,但必须付了钱,才会发货,生成发货单。
  • 数据完整性:淘宝网下订单必须登录账号,没有账号就不能成功购买。
  • 工作流:搜索裤子-找到合意裤子-下单购买-付账-收货。
  1. 业务逻辑:搜索“裤子”-找到合意裤子-下单-必须登录账号-结算-付账-收货。

    当当必须登录账号才能下单成功,亚马逊就不需要,今天发现淘宝也不需要登录账号就能购买商品了,所以每个网站的规则的不同,就形成了不同的业务逻辑,业务逻辑不仅仅包括规则,还包括实体、数据完整性、工作流。如图:

  2. 业务逻辑图:业务逻辑也需要画图,叫做业务逻辑图,它跟业务流程图有什么区别呢?

    业务流(工作流)是业务逻辑的一部分,它定义了对象之间的交互关系,但不涉及到规则的制定,数据的完整性方面。
    其实,我们平常画的业务流程图多数是业务逻辑图。

  3. 表示层

    分层是为了实现“高内聚,低耦合”。采用“分而治之”的思想,把问题划分开来各个解决,易于控制,延展和分配资源。

所谓的三层开发就是将系统的整个业务应用划分为表示层,业务逻辑层和数据访问层,这样有利于系统的开发、维护、部署和扩展。

分层是为了实现“高内聚,低耦合”。采用“分而治之”的思想,把问题划分开来各个解决,易于控制,延展和分配资源。

业务逻辑层负责系统领域业务的处理,负责逻辑性数据的生成、处理及转换。对所输入的逻辑性数据的正确性及有效性负责,但对输出的逻辑性数 据及用户性数据的正确性不负责,对数据的呈现样式不负责。

JavaEE三层架构MVC,把视图控制器模型分开来

那么在这里业务逻辑就是M。

但是什么样的算是业务逻辑如:上传一个文件,上传代码算是一个业务逻辑吗?

数据库操作增加时需要判断,和一些其它这算业务逻辑吗?(我觉得算)

但是hibernate又提供了一个离线查询对象(DetachedCriter),提供这个接口的意思我想是在外面处理业务逻辑。

但是三层架构不是独立的吗?互相不干涉吗?在service层出现sql,hql,criter不是又把dao与service连在一起了吗?

DTO(VO),POJO,BO这些是什么,POJO对应数据库,BO对应业务逻辑,DTO对应页面的传输与显示。

业务逻辑就是处理数据的逻辑啦。

后台代码分三层

  • action(controller) service DAO (这里的三层不是MVC)

比如 我得到用户名 但是在存入数据库的时候 用户名字段应该是前台的用户名加上当前日期拼成的字符串

  • action或者controller层是第一层 一般是用来及接受数据并且做数据的非空啊 格式是否正确的验证

    如用户名是否为空 是不是安全字符串之类的

  • service层一般是用来做一个业务逻辑的实现

    这时候 userName = userName + new Date();

  • DAO层 就是与数据库交互层

    也就是读写数据库 将逻辑层得到的新的userName插入到数据库

MVC和三层架构并没有可比性

三层架构是指将程序分为数据访问、业务处理、界面三个层次,是软件整体架构

MVC是仅仅是界面架构,也就是它其实只是三层架构的界面部分

  • M是指实体模型或者实体模型的一个代理,而非领域模型
  • C是指控制器,仅仅是做转向,不应该包含任何业务逻辑
  • V就是视图

至于那些个什么什么O,都是实体在不同层的映射。另外值得一提的是,MVC在一些小的程序中也经常被当做软件整体架构,那个时候M往往就是实体模型了,但是这种时候,V就对M产生了直接引用,也就是界面对实体产生依赖,这是很不好的(但小程序问题不大),此时可以尝试使用MVP模式解耦。至于业务,看你怎么定义领域模型了,一般像上传文件这种操作并不会牵扯企业的业务,那就不应该当做一个业务,但如果这个上传是在工作流或者一些特殊处理中,则有可能上升到业务。怎么做,要看具体问题。

Donate comment here
Title - Artist
0:00