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

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

 

by:授客 QQ：1033553122

 

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

 

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

什么叫业务？

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

举例：

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

 

什么叫业务过程？

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

 

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

 

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中是否验证过，服务端（可能是表示层的服务端部分或业务层）一定要再进行验证。