架构师面试（二十八）：业务建模

问题

今天我们撇开纯技术，聊一下关于【业务建模】的话题。

何为业务建模？即通过易于理解的模型将业务中的关键问题准确表达出来。

业务建模是需求分析环节乃至整个软件生命周期中非常关键的一环，它几乎决定了软件的开发周期和成本。下面关于【业务建模】的相关描述中，说法正确的有哪几项？

A. 在分析不管是已经运行的软件系统还是产品描述的业务系统时，可以首先区分【功能需求】和【非功能需求】，对于前者再分析出【基础功能需求】和【扩展功能需求】，而对于后者在互联网中一般是分布式系统的三高需求；

B. 对需求进行业务建模时，如果发现逻辑或流程存在不能闭环的情况，必须立刻反馈给业务方对需求进行确认；闭环是验证需求可行性的唯一关键指标；

C. 业务建模的工具或方法有很多，包括 E-R 图、UML、SA、OOA、DDD 等；

D. 对需求进行分析和建模时，需要区分出业务稳定的模块单元和业务容易变化的模块单元，前者往往是系统的核心，而后者往往是系统的扩展。

解析

【业务建模】通过非常容易理解的模型将业务系统的关键问题表达出来，方便业务人员、开发人员、测试人员对业务系统的理解保持高度一致，可以减少后续对软件系统的频繁修改，从而起到【降本增效】的作用；希望大家对【业务建模】保持高度重视！

当我们面对产品经理提的一堆需求时，或者去熟悉已经存在的软件系统时，有没有一个思路框架进行指导呢？

当然有的：可以首先区分【功能需求】和【非功能需求】，对于前者再分析出【基础功能需求】和【扩展功能需求】，而对于后者在互联网中一般是分布式系统的三高需求；【基础功能需求】往往是业务系统中非常稳定的模块单元，不会轻易修改和变化，这就是系统的核心；而【扩展功能需求】往往是业务系统中经常变化的模块单元，这是对系统核心的扩展。(详见《架构技能（四）：需求分析》)

举一个例子：在IM系统中，【私信消息】就是【基础功能需求】，而【红包】【语音通话】就属于【扩展功能需求】；【扩展功能需求】的实现一般都是基于【基础功能需求】进行的。所以，把握好系统的【基础功能】也就把握了系统的核心和关键。

业务建模的工具和方法非常多，比如 数据库建模工具E-R 图、统一建模语言UML、结构化分析SA、面向对象分析OOA、领域驱动设计DDD 等。

对需求进行业务建模时，如果发现逻辑或流程存在不能闭环的情况，必须立刻反馈给业务方对需求进行确认；闭环是验证需求可行性的一个经常使用的关键指标，但不是唯一的指标。【闭环】更多的是验证需求的逻辑性是否合理；需求可行性除了逻辑性之外还有经济可行性（投入产出比）、技术可行性（三十年前的手机实现地图导航简直匪夷所思）、操作可行性（是否合法等）。

参考答案

ACD