背景

上一篇文章 如何设计智慧农业系统架构 中我们归纳出了智慧农业系统具备的基础业务单元，也已经大致有了一个农业系统的架构思路。

但同时我们也感觉到，各个业务单元与整个系统体系还是很分散，没有一种强有力的表达让他们联系在一起，而这样确实也是系统架构图表现的局限性。

这一次我们站在客户和老板们的角度，来通过业务架构串联起整个系统的业务单元，并且还需要通过数据流向清晰的了解整个系统的数据架构。

业务单元

我们在上一章归纳的业务单元分层图。

根据上一章这些业务单元使用到的服务，我们罗列出当前的中间层服务清单、第三方服务及其调用路径。

业务单元	角色及调用方	服务调用路径 ->：系统内调用 …>：系统外调用	数据表
需求管理	用户 - App	需求转换服务 -> 种植模型生成服务	种植模型表
	用户- 小程序/App	需求管理服务	用户需求表
供应管理	运维人员 - Web/小程序/App	供应管理服务	供应来源表
	运维人员 - Web/小程序/App	供应管理服务 -> 供应采购服务 …> 第三方商城服务 …> 订单管理服务	订单表
	运维人员 - Web/小程序/App	供应管理服务 -> 供应采购服务 …> 第三方商城服务 …> 物流管理服务	物流表
		定时任务服务 -> 感知采集服务 -> 消息通知服务 …> 第三方短信服务
感知采集	终端机控制程序	感知采集服务	感知数据表
控制调度	终端机控制程序	控制调度服务	调度数据表
		定时任务服务 -> 感知采集服务 -> 模型纠偏服务 -> 控制调度服务	调度数据表
		定时任务服务 -> 感知采集服务	感知数据表
模型处理	运维人员 - Web/小程序/App 用户 - App	模型管理服务	种植模型表
	运维人员 - Web/小程序/App 用户 - App	模型管理服务 -> 种植模型生成服务	种植模型表
模型纠偏		定时任务服务 -> 模型差异服务 -> 模型预期服务 -> 模型优化服务	种植模型表
库存管理	运维人员 - Web/小程序/App	库存管理服务	库存表
		定时任务服务 -> 库存识别服务 -> 库存管理服务	库存表
		定时任务服务 -> 库存识别服务 -> 消息通知服务 …> 第三方短信服务
		定时任务服务 -> 库存识别服务 -> 感知采集服务	感知数据表
销售管理	用户- 小程序/App	订单管理服务	订单表
	用户- 小程序/App	订单管理服务 …> 第三方支付服务
	用户- 小程序/App	订单管理服务 -> 库存管理服务	库存表
物流管理	用户- 小程序/App	物流管理服务	物流表
	用户- 小程序/App	物流管理服务 …> 第三方物流服务
	用户- 小程序/App	物流管理服务 -> 订单管理服务	订单表

业务流程

上面我们梳理了业务单元内部功能的调用路径，当然这个是站在纯技术视角的。我们还需要根据：数据驱动生产的生产核心将其抽丝剥茧，取出其核心业务，帮助我们能更快的抽象出核心的业务流程。

我们再次明确系统的业务需求：

• 生产是可以自动进行的，生产的参数也是需要不断被系统优化和纠偏的
• 生产是可以被用户主导的，但用户主导的前提是根据系统预设维度定制生产模型

通过上面的功能调用路径和抽象视角，我们能很清晰的察觉到各个业务单元之间的业务权重。所以根据业务权重、调用关系以及业务需求，我们可以画一个核心的业务流程。

业务架构

根据上面的业务流程，我们再结合上面梳理的业务功能点，合并整理为一个业务矩阵，也可作为业务架构图的原型图。

根据上面的业务矩阵，我们对整个业务体系已经有了大概的理解。而业务架构图需要将这些矩阵中的功能，根据其业务属性归类，形成业务模块，按照从上到下顺序的堆叠“层”。

这过程需要高度的抽象“业务属性”，我们的方法是：抓住核心，向四周扩散。

核心，是指整个系统的核心业务，比如我们的智慧农业系统核心是数据驱动生产，那么对应的核心业务就是数据和生产。而在我们的系统中，数据对应的就是模型，生产对应的就是感知控制设备。

四周，是指从这核心出发，不断的去触达各个业务单元，在触达的过程中，去归纳不同的业务单元，直至覆盖所有的业务单元。

这样我们的业务架构图就基本成型了。

总结

每个人面对业务的复杂度不同，但核心思想都是一样的，先抓核心的业务，然后不断的扩散它，扩散的边界其实就是业务单元的边界。

必须走的流程就是：梳理业务单元 -> 梳理核心业务流程 -> 归纳业务功能矩阵 -> 分层业务架构

后面的文章就是围绕这个智慧农业系统，我们逐步的去实现它。下一章就是设计数据库的表、字段。