要想解决一个问题，首先要能明确的定义什么是问题，它从何而来，它的边界又在哪里。

系统上下文是什么



System context，中文系统上下文。系统上下文是整个架构设计的开始。一切的一切，从边界开始梳理。这里也是整个分层架构设计的起点。那么系统上下文到底是啥呢？这里系统上下文主要包含2点：



1. 系统边界；

2. 外部接口；



系统上下文图，其实没有什么固定格式。一切能把这两个问题讲清楚的图皆可。不过咱们实践的过程中，还是有一些需要注意的地方。下面举个栗子：



以上是我找到的一个文件系统的系统上下文(非常抱歉，我不可能将真实的项目拿出来给大家分享)。大家可以看到，在系统上下文中，不光需要将交互的系统描述出来，同样使用系统的人也要表示出来。而且，就个人经验，人和系统要分隔开，用不同的图例表示。在看图的时候，经常能发现将使用系统的人，或者和系统交互的人忽略掉了。严格的来说，这可能会产生一定的信息缺失。严格的来说，系统上下文应该说明系统和外部交互的人或系统的交互方式。不过这些在第一步时，并不是那么重要，后面会有机会补齐。

系统上下文不是什么



系统上下文并不是系统架构图。它不应该包含系统有哪些组件或如何实现~！所谓分层思考，就是要限制问题的范围，集中精力解决该层次最重要的问题。在这个层次中，系统上下文描述的是系统外部的连接的人和系统。这是一个逻辑上的概念，和实现无关~！一个IT架构设计，是从逻辑视图逐渐过渡到物理实现视图。那么系统上下文阶段，就是逻辑视图阶段。



架构魔方



Next！

其实讲到这里，一切还平淡无奇。希望能看到架构炫酷技术的同学们可能要失望了。是的，因为系统上下文并不是一个archivement 要件，而是一个下一阶段工作的索引，或者说开始。



这里会涉及到系统架构工作的下一步：Architecture Overview。Architecture Overview 会描述系统内部的组成。但这里咱们不展开 Architecture Overview 是什么。关于Architecture Overview 的内容咱们后面会详细的展开说。这里只看一个问题：Architecture Overview中的所有输入是不是都是从 System context 来的。



以上图为例，当FFDS系统展开之后，会有若干个Component 或者sub system。这些Component 或者 Sub system 都需要和System context 的内容产生的一定的联系。如果存在某个component 孤岛，或者System context 并未指向 Architecture Overview 中的任何component。那么架构设计一定存在问题。要么是这个component 识别出了问题，要么就是System context 识别出了问题。亦或者两者都出了问题。此时就要回过头来，重新去审视系统上下文。该补的补，该改的改。对系统上下文的补充也同样会影响到Architecture Overview，那就该重画的重画，该补足的补足。直到所有的系统和人都被识别出来。一切都是连接的、自证的。



总结



系统上下文是整个架构设计的开始。但其工作并不是画个图就没事了。系统上下文的识别工作甚至可能会贯穿整个系统架构设计工作的始终。架构师应该始终细心的对待每一个在架构设计中出现的每一个元素。清晰描述它们之间的关系，它们如何相互作用，完成系统的需求。没有遗漏，也没有多余，一切刚刚好(嗯，严格的说，要比刚刚好，多那么一点点，但不是过度设计)，便是好的架构设计。



最后，给大家留一个疑问。系统上下文的输入有是什么呢？有兴趣的同学可以在留言。下一节，咱们会聊到整个架构设计中最重要的一个环节：Architecture Overview。下节见 ：）