前言

Github：https://github.com/HealerJean

博客：http://blog.healerjean.com

一、系统内、系统外

系统边界总这样含糊不清地存在着：开发团队嘴里说着“系统”，其实连系统的范围到底有哪些都语焉不详。这是许多软件项目的真实状况

在人类的日常事务经验中，几乎不可能将‘在系统之内’和‘在系统之外’清楚地区别开，生活是由许多连接并交织又常常不协调的‘系统’组成的，用‘系统内’‘系统外’这类词汇来思考似乎过于简单化了 。

在架构映射阶段，我们不能想当然地认为团队成员都理解了系统的意义，并能清楚地区分系统内和系统外。这就解释了为何要为软件系统引入系统上下文。

二、系统上下文

“系统上下文代表了目标系统的解空间。

要注意，问题空间和解空间的边界并不一定完全重叠。在确定系统上下文时，可以从目标系统向外延伸，寻找那些虽然不是本系统的部件，却对系统的价值体现具有重要意义的对象：这些对象就是目标系统范围之外的伴生系统（accompanying system）。伴生系统位于”“系统上下文的边界之外，但它提供的功能可能属于问题空间的业务需求范畴。

1、伴生系统

伴生系统的类型直接影响了目标系统与伴生系统的协作。如果目标系统与伴生系统对应的团队处于同一组织下，就有了紧密协作的可能，目标系统所在的团队甚至可以与伴生系统共同协商接口的定义

如果伴生系统是对外采购的外部系统，我们作为采购方，就具有一定的控制权，可以决定选择哪一款系统，这一决定可以作为架构决策的一部分。

2、系统上下文图

“可以通过系统上下文图表示系统上下文。在系统上下文图中，两种颜色的框图各自代表目标系统和伴生系统，整个系统上下文图如下图所示，以目标系统为核心，勾勒出用户、目标系统和伴生系统之间的关系。

“系统上下文图不会展现目标系统的细节，目标系统是一个黑箱，代表解空间的边界，环绕在解空间边界之外的是目标系统的外围环境，如此即可直观地体现“系统内”与“系统外”的内涵与外延。”

1）系统上下文的确定

全局分析阶段输出的价值需求有助于确定系统上下文。

a、参考价值需求

价值需求中的利益相关者可以充当系统上下文的用户，系统范围可以帮助界定系统解空间的边界，分辨哪些功能属于目标系统，哪些属于伴生系统，也就是区分“系统内”和“系统外”。

对解空间边界的确定还需要结合系统愿景进行判断，因为在进行设计决策时，与系统愿景不相匹配的功能往往不会作为目标系统的核心功能，

举例：以一家经营网上书店的企业为例。企业的战略目标是拓展线上销售。为了满足这一战略目标，要求开发一个个性书店系统。该系统的愿景是为顾客提供个性化的购书体验，以达到提高在线销售量的目的；系统范围主要包括在线销售与售后服务；顾客、商家和配货员是该系统的利益相关者。

根据企业当前的业务生态与运行状况，结合目标系统的愿景和范围，明确推荐、支付和配送属于目标系统之外的伴生系统。推荐功能由推荐系统提供，作为企业内的系统由另一个团队负责开发和运营维护，在获取顾客的购买偏好与个性特征后，结合大数据建立推荐算法模型，提供高匹配度的图书推荐服务；支付功能与配送功能分别由企业外部的第三方支付系统和物流系统提供服务。由此确定了用户、目标系统和伴生系统之间的关系

b、业务序列图

系统上下文图虽然直观体现了企业级的利益相关者、目标系统和伴生系统之间的关系，但它主要体现的是这些参与对象的静态视图。要展现目标系统与伴生系统之间的动态协作关系，可以引入业务序列图”

业务序列图实际脱胎于 UML的序列图。序列图可以从左侧的角色开始，体现消息传递的次序。这隐含了一种驱动力：我们每次从左侧的参与对象开始，寻找与之直接协作的执行步骤，然后层层递进地推导出整个完整的协作流程