Java架构师系统架构设计确定系统边界

---

想学习架构师构建流程请跳转：Java架构师系统架构设计
# 1 项目背景

相关文章

千万级订单生成的痛点与架构：https://blog.csdn.net/ZGL_cyy/article/details/125830853
设计模式之状态模式与备忘录模式详解和应用:https://blog.csdn.net/ZGL_cyy/article/details/129106197
需求分析和常见的需求问题解决：https://blog.csdn.net/ZGL_cyy/article/details/126438005
Mysql分表分库背景知识：https://blog.csdn.net/ZGL_cyy/article/details/118278444
高并发系统深度优化：https://blog.csdn.net/ZGL_cyy/article/details/124819700

大家都知道实战的内容呢一定是要基于实际的项目来做。那为了更好的去理解项目的业务场景以及业务功能，我们首先呢来对这个项目的背景做一些了解，一起来看一下。b2b的电商业务一年呢能做到百亿以上。总投入超过了四百五十个人/月。

运营模式客户是到这个平台方来进行采购。b2b平台方销售的是两类商品，一类是自有的商品，一类是各位供应商提供给他的商品。

那么对于企业客户来讲呢，他只面对b2b平台方，有可能企业他这次采购，但涉及到十家的这个供应商。但是对企业来讲，他就只有一个供货方啊，就是b2b平台方。那么b2b平台方会去向多个供应商采购这些商品，加上他自有的商品，形成完整的这么一个商品包给到企业，大概是这么一个意思。这样呢就自然形成了完整的一个供应链。
另外大家还要知道的是，整个项目虽然是以to b为主，但是呢它同时也有to c的部分。只不过呢企业是集采就集体采购，那么金额会比较大。所以说呢他主要还是针对这些企业来进行服务。但是呢也有针对个人的，就类似于商场，他也走这个b2b平台，所以说呢这个地方啊就变成这样。

个人呢到这上面，那就是购买。他就不是采购了。就完全跟咱们to c的这样子的一个电商网站是一样的。就到上面进行购买。
购买商品吧。那对个人来讲，他也无所谓是b to b平台方自有的商品还是供应商的商品。反正觉得这个商品不错，价格也不错，可能就买了。那就跟咱们上电商网站是一样的。那这个呢就是整个项目的一个业务背景。

2 初始业务场景分析

在具体进行需求分析之前，我想做几点提前说明，咱们尽量达成共识。

2.1 业务的需求分析重要性

大家千万别忘记了，我们是做软件的。软件呢它不过是个工具，是个用来帮助用户解决相应业务问题的工具。所以说我们去理解业务是非常重要的。我们做的软件就是要用来解决这些业务问题。对于一个架构师而言，如果说他的业务都不理解，也就是说他根本不知道要做什么。那他做的架构设计是在设计什么呢？因此啊在实际工作当中，我们在面试架构师的时候，都是先问业务方面的问题。比如说业务背景、业务架构、各业务块的关系等等的。如果说这个面试人业务回答不过关的话，说实话问技术的兴趣都没有。因为这说明了要么就是简历造假了，根本没有做过架构师。要么就是一个水货，或者说是一个ppt级别的架构师，这都不是我们需要的架构师。所以对于架构师而言必须。

2.2 全面深入的理解业务从零到一从无到有

做架构设计的一个前提全面深入的理解业务从零到一从无到有，那架构师理解业务的这个阶段呢，就是在需求分析这个阶段。前面也讲了需求分析是架构设计的一个必备基本功。因此呢这里咱们再次强调，对架构师而言，需求分析很重要，这是第一个要强调的。再看第二个。架构设计，它其实就是从零到一，从无到有的。大家试想一下，现在我们手里只有需求调研回来的资料，只有用户的需求。
从软件的角度来说，现在还是零，对吧？架构师呢就是要去分析和理解用户的需求，把软件做成什么样给我描绘出来，设计出来并且确定下来。也就是说架构师做的就是一个从零到一，从无到有的事情。这也是有一些人呢他觉得架构师很高深，有些玄奇所在。其实呢架构设计一点都不神秘，只要按照我们讲的经济架构设计法，按照讲述的这些步骤方法思路去做架构设计，还是比较容易的。当然具体的呢随着咱们课程的推进，大家会一点一点去体会。

2.3 需求分析

前面咱们讲项目背景的时候也提到了，这个项目非常的大，好几百人月的工作量，不可能都去讲，只能够从这里面去挑出一些业务场景，作为咱们实战内容的业务部分。那我们现在呢就挑出了这个业务场景，就是客户正向下订单的这么一个业务流程。
具体的这个内容呢大家看一下，在这儿会给大家看一个订单需求的说明书。
大家看一下，这是一个下单的流程图。然后下面呢有相应的一些场景描述，就是这个具体的说明。

流程说明：

1） 商品是否支持预订在运营端进行维护，商品的SKU以及所在的仓库决定了预购起订量。

2） 卖家预定后可以和销售顾问线下议价，销售顾问可以在运营端修改该笔预购订单的商品预定量以及总价格，送销售主管审核，此时该笔订单涉及的商品库存被扣减。

  库存锁定的时间默认为24h，销售顾问可以在到期之前进行以小时为单位的延期，超期订单未支付，则库存释放。

3） 销售主管在运营端对该笔订单的相关情况进行审核，审核通过后，卖家在微信端收到该笔订单的预定金待支付通知，卖家可以在APP端支付预定金。

  目前APP端订单的支付方式支持：线下转账、线上支付。

  改价前：  预订价*数量+其他费用= 总价 

                  总价*预定金比例（全局配置）= 预定金

  改价后 ：改价后的总价*预定金比例（全局配置）= 最终预定金

  如果卖家选择线上支付，支付完成后，该笔预售订单状态设置为预定金已支付状态。

  如果卖家选择线下转账，支持卖家在APP端上传转账记录，或者销售顾问在运营端上传转账记录，订单状态设置为预定金已支付待审核状态；

4）财务人员通过运营端审核该笔预购订单，审核通过则订单状态设置为预定金已支付状态。

5）相关负责人进行预购商品的采购和入库操作。

6）销售顾问在运营端设置改币预购订单为可支付尾款，订单状态设置待付尾款状态。

  尾款=改价后的总价格-最终预定金

7）卖家在微信端收到该笔订单的尾款待支付通知后在APP端找到该笔待支付订单，进行支付。

 如果卖家选择线上支付，支付完成后，该笔预售订单状态设置为尾款待审核状态；

 如果是线下转账，支持卖家在APP端上传转账记录，或者销售顾问在运营端上传转账记录，订单状态设置为尾款待审核状态。

8）财务人员通过运营端审核该笔预购订单，审核通过则订单状态设置为已支付状态。

3 系统和系统边界定义

系统边界是指系统包含的功能与系统不包含的功能之间的界限，也就是区分系统内部和外部的标志。系统内部是指我们要开发或维护的部分，需要投入大量的精力和资源；系统外部是指我们不需要开发或维护的部分，但需要考虑与它们的交互和接口。系统外部可能包括用户、其他系统、软硬件条件等。

3.1 为什么要确定系统边界

确定系统边界是进行需求分析和设计的重要步骤，它可以帮助我们明确项目的范围和规模，定义要创建或改进的系统的那些部分。确定系统边界也可以帮助我们识别与系统交互的所有外部对象，也就是执行者，以及他们对系统的需求和期望，也就是用例。执行者和用例是用例分析技术的核心概念，可以用来描述系统的功能和行为。

确定系统边界还可以帮助我们避免需求冲突和设计错误，因为我们可以清楚地区分哪些事情属于我们的责任，哪些事情不属于我们的责任。如果没有明确的系统边界，我们可能会做一些不必要或不合适的工作，或者忽略一些重要或紧急的工作。

如何确定系统边界确定系统边界需要采用一些方法和技术，例如：

通过提问法来寻找执行者和用例。例如：谁使用这个系统？谁安装这个系统？谁启动这个系统？谁维护这个系统？谁关闭这个系统？哪些其他的系统使用这个系统？谁从这个系统获取信息？谁为这个系统提供信息？是否有事情自动在预计的时间发生？执行者希望系统提供什么样功能？系统存储、创建、更新或删除什么信息？系统是否需要把自身的状态变化通知给执行者？系统必须知道哪些外部的事件？执行者怎样通知系统这些事件？
通过画图法来表示执行者和用例。例如：使用系统上下文图（也叫系统关联图）来表示一个简单的黑盒子视图，显示出与之交互的执行者和数据流；使用用例图来表示一个白盒子视图，显示出执行者与用例之间的关系。

通过文字法来描述执行者和用例。例如：使用简洁明了的语言来说明执行者和用例的名称、目标、范围、前提条件、后置条件、主要流程、异常流程等。

3 需求分析明确系统边界

系统是指具有某种功能的稳定结构，比如人体就是一个系统，具有走路跑跳等功能，身体各部分以一定的方式连接在一起，形成一个稳定的结构。系统可以是软件、硬件或者过程，只要它能完成一定的任务或目标。

确定系统边界包含但不限于技术架构、部署架构、安全架构、存储架构等等。知道在高层架构的设计阶段，架构师要做什么，也就是做高层架构设计的一些基本方法项目就是年交易两百亿的b2b电商平台订单系统。

我们的这个系统简化到就是我们选取的这一个场景，就别的我都不做了，我们整个项目浓缩下来就只做这一个场景。
那我们是不是也应该有一个明确的系统边界？那这一块呢单纯从咱们前面讲的这个业务流程上，是看不出来系统边界的。
因为我们前面讲过，所谓系统边界指的呢是看这个系统和其他外部系统之间的一个关系。
那这个里头大家看好像没有涉及到外部的系统对吧？

咱们现在只是去画一个初步的这么一个系统边界图。随着咱们对业务的深入理解，还会进一步的来完善它。所以说我们先画一个，比方说这个框框就代表了我们现在要做的系统。其实现在暂定的就是一个客户。正向。下单的业务流程。是这样子的吧。那好，那属于系统边界呢，你看这个黑线框就相当于是边界了嘛，那么框内的是我们内部要做的。框外的就是外部的系统。所谓明确系统边界，就是明确我们这个系统和外部这些支撑系统之间的一个关系。事实上呢对于整个项目来讲，它外部啊大概有大大小小的系统呢十几个，当然咱们这里呢不用去讲那么多，咱们讲几个呢意思一下，而且呢尽量跟咱们这个订单业务有关的外部统。

4 高层架构设计

深入理解高层架构设计之道，包含但不限于技术架构、部署架构、安全架构、存储架构等等。知道在高层架构的设计阶段，架构师要做什么，也就是做高层架构设计的一些基本方法。

通过准确全面深入的需求分析，我们搞清楚了到底我们要做什么。形成的可落地的业务架构，以及呢完整的功能点列表，还有呢咱们的需求分析的技术说明文档。也就是说呢需求分析的成果物就作为咱们高层架构设计的输入的原始的一些材料。
高层架构设计就是基于需求分析的结果来继续进行。

大家看第一个高层架构设计阶段呢，主要是关注高层和整体，一般来说跟具体业务的关系比较小。也就是说我们在高层架构设计阶段比较少的去考虑具体的业务实现。当当然不是说完全不考虑设计，但是呢考虑的不会很细。它主要的目的呢是对整体系统进行粗略的概念的设计计来确定整个系统的主体结构。简单点说，高层架构设计阶段就是在对整个系统画大框框。

那么我们有了这个高层架构设计过后，我们就要对它进行细化。又分了两个阶段，一个是概要设计阶段，一个是详细设计阶段。
概要设计阶段呢就是在高层架构设计的基础之上，关注具体的实现和落地。一般来说呢这个时候啊就跟具体的业务相关的。
比如说高层架构设计比较少考虑这个业务，但是到了概要设计阶段，那么咱们就要把业务加进来。在概要设计阶段呢对业务实现粗略的概要的设计，以确定整个业务功能实现的主体结构。大家看一下是不一样的。

高层架构设计阶段是对整个系统画框框，而概要设计阶段是对整个系统要实现的业务功能。画框框就是更近了一步，已经跟业务结合上了。那么再看一下详细这一阶段呢，他关注的是具体的实现和落地。也就是说他一定是跟具体业务相关的。
它主要是对业务实现的详细的、可落地的、可执行的一些设计方案。也就是说，在这个阶段，我们需要确定业务功能的具体实现方案。

概要设计已经画了业务实现的这个框框，而详细设计就是把它变得更清晰，变得更详细，变得更可落地。那这些内容呢是咱们前面已经讲过的了。而我们现在所说的这个高层架构设计，指的呢就是我们这里的第一个阶段。那么在这个阶段大概要干些什么事儿，大家就比较清楚了，我们更关注的是高层和整体，较少的关注业务。那接下来呢我们具体的看一下在高层架构设计阶段，架构师要做些什么。当然这个阶段比较大，架构师要做的事情也比较多。所以说呢我们这里罗列了一些叫做包含但不限于架构师首先要去做技术架构，然后要去做部署设构，再去做安全架构，还要考虑存储架构。当然除了这些，还有一些其他的架构也需要在高层架构设计，根据需要来选择。所以说咱们这才说是包含但不限于。那对这些内容呢，我们稍微展开一点描述一下。
首先呢咱们要确定高层架构设计阶段。就咱们刚说的这个高层架构设计阶段。应该说啊是架构师的主战场之一。很大一部分啊跟技术相关的架构设计能力就体现在这个阶段。

4.1 技术架构

那大家要注意技术架构设计的其实也很多。比如说平台的架构、开发的架构、数据库的架构等等的那这些都统称是技术架构，大家可以理解成就是技术方面的架构。技术方面的架构。比如。像平台架构。开发架构。还有数据库架构。那么除了这些呢，你要稍微再细一点，比方说你的缓存体系或者缓存架构。
你的义务消息架构就这些东西，你可以先不结合具体的应用，但是呢先把大框框拿出来。
这些啊都是技术方面的架构，所以说我们点点点吧，这个还有很多，只要是技术方面的架构，那都可以靠到这个技术架构上来。

4.2 部署架构

那部署架构呢？就是考虑未来咱们这个系统该如何去部署，进一步到软硬件的架构。
比方说我需要多少软硬件，可能就要进行资源估算。
然后呢，这个软硬件之间应该是一个什么样的架构形式，包括网络架构等等的那这些都是要在部署架构上进行考虑的。

4.3 安全架构

这个呢也在这儿稍微写一下。安全架构呢也涉及到很多层次。比如说像防火墙的服务呢，进入系统的时候向网关进行的健全啊，或者是数据进入到系统的时候，我们怎么样加密啊，怎么样保证它传输的安全呢？

保证它存储的安全呢等等的。除了这些呢，还有类似于像抵抗业务攻击呢a p i的回放呢，或者说更专业的一些系统，就是跟业务规则结合的风控系统呢。这些都需要咱们在安全架构里面来考虑。

4.4 存储架构

放到这儿来。咱们做系统的时候啊，可能有很多数据需要去存储，不仅仅是存放到数据库，可呢还有很多数据需要根据数据的要求还有特点分别存储到。比如说像nosql啦、文件啊，或者是一些网络存储设备呢，还有包括容灾了备份恢复呢等等的。
这些啊都需要我们去做存储架构的设计。

那是不是除了这些我们就不用考虑其他的事情了呢？
不是这样子的，事实上在高层架构设计阶段需要考虑的还有很多。比如说我们的系统需要和其他第三方系统进行结合，那么这就涉及到你的应用集成架构是什么样的。如果咱们的系统要开放接口给其他外部系统来使用的话，那我们就可能要做open api的开放架构。这是不是也要我们做架构设计的等等的吧。那这些东西都是咱们在做高层架构设计阶段要考虑的内容。

当然啊这里提醒大家一点，就这个阶段一般只考虑高层的架构或者说是结构的形式，尽量不去考虑业务功能的具体实现，这个啊算是一个题型高层架构设计阶段。一般。只是考虑他楼上来的啊。系统的。高层的。架构或结构形式。
尽量的。不去考虑。业务功能的具体实现，即使要考虑也是很粗略的。或者说这个重难点的功能对于咱们整个架构形式可能会产生影响的。那么具体怎么实现这些业务，咱们这里呢不要去考虑这些东西。那对业务功能的具体实现这些工作呢，咱们可以放到后面的概要设计啊详细设计阶段再去做。这一点呢大家要注意，就说这其实啊也看得出来，咱们是在采用迭代的思想。
也就是说我们做的这个架构设计并不是一蹴而就的。不是说一上来做所谓的高层架构设计，就已经把这个架构设计做的很好了。
不是的，我们也给他分了很多层，大家看我们前面是不是分了三个层次。
每个层次有自己的关注点，是说你的整个架构设计是不断在细化的。经过多次迭代过后，那么你的整个设计方案。
就会清晰起来。所以说呢每一层有每一层的任务。咱们现在做高层架构设计阶段，就尽量不要去考虑业务功能的具体实现。
了解了架构师在这个阶段需要做什么过后，一起来看看架构师做高层架构设计的一些基本方法。
其实呢对做架构设计来讲，并没有什么特别通用的放之四海而皆准的方法。

所以说市面上呢才会有各种各样的架构设计的方法论。但是每一种方法论呢都有自己的适用场景，有自己的一些局限。
包括我们现在给大家讲的基本方法，也是我们自己经验的总结。可能跟很多市面上大家看到的方法论是不一样的。
根据我们多年做架构设计的经验，不管做什么样的架构，基本上啊还是会遵循一定的方式的。把它稍微总结一下，就形成了下面这样的方法。大道至简基本设计思想之一。从大到小，由粗到精，逐步细化。事实上架构师在做高层架构设计的时候，它的一个基本的指导思想就是这个不断的在从大到小，由粗到精，逐步细化去做咱们每一个部分的架构设计。
至于这个方法呢，咱们前面已经单独的去讲过了，咱们这儿呢就不再去啰嗦了。
那么具体的怎么样把这个基本的设计思想落实到实处，用它来指导咱们的高层架构设计呢？
咱们在后面的课程当中逐步去体会。
那前面咱们也讲了，这个基本的设计思想不仅仅应用在高层架构这一阶段，包括后面的概要设计啊，详细设计了等等的，都可以用这样的方法来做。
只不过呢在不同的层面，那么大家的关注点是不一样的。
但是基本的指导思想都是从大到小，由粗到精，逐步细化。

5 高层架构设计确定系统边界

核心思想：

明确系统该做什么，而不做什么明确系统与周边系统的关系
明确系统在整个大业务场景下的定位
明确系统的运行环境以及前置条件

看到这个标题啊，可能有些人会想起来，我们在需求分析阶段是不是也有一个明确系统边界。那这两个还是有明显的不同的。
我们在需求分析阶段去讨论明确系统边界，主要是从业务功能的划分上来说的。

我们只需要知道说我们的功能做abc好d我不做d的功能呢是由第三方系统来做，这是在需求分析阶段明确下来的。而咱们现在要讨论的确定系统边界呢，是要在需求分析的基础之上怎么样去讨论实现。就说我不能只知道我做a b c然后d呢是由第三方系统做。

5.1 和第三方系统进行交互

我们交互的方式、交互的频次、交互数据量等等的，我都需要去考虑。我要把这些东西的确定下来。毕竟咱们现在要去考虑如何做系统分析，如何落落地。那这些内容呢就是高层架构设计的确定系统边界里面要思考的。那我们先来看一下，在高层架构设计阶段确定系统边界的话，架构师到底需要做些什么？当然啊这个也是包含但不限于。先来看第一个，架构师需要明确系统在整个大业务场景下的定位。这个呢就是要理解在用户整个的业务场景当中啊，我们的系统到底承载的是哪一部分。用户的业务可能会比较多，也比较复杂。比如说它有生产的、设计的、制造的、销售的、客服的、物流的、财务的等等各种各样大业务场景。
我们做的系统呢，假设说就是电商系统吧，那么实际上做的就是销售这个大业务场景下面的一部分。
那我们只要明确的这个，我们就知道在咱们电商系统里面就不会去设计什么生产的设计啊，制造啊等等这些业务。
即使咱们里面有一些功能，需要用到这些块的功能，那么我们也只是去调用，而不是说我们自己来实现这样子的一些功能，是这个道理吧？

进一步来想，就算是在销售这个大的业务场景下，可能我们做的系统啊也只是其中的一部分。比如说客户的销售可能又分成线上销售和线下销售。他线下销售有它传统的渠道，有他自己地面的推广网络。那线上呢它可能也分了很多种，比方说有to b的，有to c的，有做b2b平台的。但这个啊也会有很多，而我们可能只是做了其中的一部分，比方说我们只做了to b的。
所以说大家就可以看得到明确系统到底在哪个大的业务场景下，具体承载哪一部分的功能，对我们理解系统的定位，明白这个系统的边界都是非常有帮助的。所以说呢这个阶段实际上是在需求分析的基础之上，咱们再次明确一下，知道咱们这个系统的定位，从而有利于我们去理解咱们的系统的功能，还有呢确定咱们系统的边界。

5.2 明确系统该做什么

那这一步呢就跟在需求分析里面的要求差不太多。
就是我们要去对我们的系统划分一个清晰的边界，知道哪些东西应该由我们的系统来做，哪一些功能呢系统是不做的，这个是非常重要的。因为呢清晰的边界有助于整个系统的架构设计和开发实现，能够更好的帮助我们去达成软件建设的目标。
比如说根据前面的需求分析，我们知道咱们的系统只需要做到下完订单过后就生成一张出货单。
然后呢把这个出货单推送到erp，这之后的业务就由erp来完成了。所以说呢我们就要明确，我们的系统就做到下完订单处理业务一直处理到生成发货单，生成发货单就是我们订单处理的业务边界。

5.3 系统和外部的系统交互关系

包括接口。包括交互的一些次数、限制啊、数据量、调用频次啊等等的就都明确下来了。就说我们不仅仅是知道了我们的系统做什么，哪些我们不做，我们还知道我们跟外部系统之间的一些关系。
我们为什么不做？是因为有第三方系统帮我们做了，但是我们可能需要这个功能啊，所以说我们就需要跟第三方系统进行交互，是这个道理吧。那么如何交互，交互的频次这些东西我们就都确定下来了。

5.4 系统的运行环境和前置条件

那我们都知道啊未来我们的系统要运行在什么环境下。比如说我们的部署环境，服务器多少、软件情况，网络带宽的多少，其他配备资源的多少等等的，这些数据都是我们需要知道的。因为这些会直接影响到我们架构设计的学习。还有呢对质量约束当中的一些关键元素的达成。比如说它要求的性能，它要求的稳定性等等的。另外我们还需要知道，如果要让我们的系统正常的运行起来，需要哪些外部的系统。因为我们的系统只是整个大业务场景当中的一部分嘛，需要从第三方系统去获取一些数据，也需要一些数据啊传递给第三方系统，否则的话又是无法完成的那这些呢也就构成了前置条件。那这些呢就是在确定系统边界这个过程当中啊，架构师需要做什么。

6 总结

确定系统边界是理解一个复杂问题或现象的第一步，它可以帮助我们把握问题或现象的本质和特征，以及与之相关或影响的因素。通过确定系统边界，我们可以将一个复杂问题或现象分解为多个相对简单和清晰的子问题或子现象，并为每个子问题或子现象设计合适的解决方案或模型。这样，我们就可以更有效地开发和维护一个具有某种功能的稳定结构，也就是一个系统。

大家一看到明确系统边界，可能就会想起来咱们在需求分析阶段是不是也有一个明确系统边界。那首先呢我们就来看一下，咱们在高层架构设计阶段的明确系统边界，和咱们前面在需求分析阶段的明确系统边界有何不同。
首先呢我们来回顾回顾，这个是咱们在需求分析阶段去明确系统边界的时候，画出来的咱们的系统和外部系统的一个关系图。

也就是说我们的系统需要外部系统提供一些什么样的功能？另外呢我们的系统又需要向外部系统去提供哪些功能？
那么在图上画的，还有在这个文档里描述的都是限于功能级别。只是描述了需要做什么，有这样子的一个功能交互，并没有进一步的描述。那这个呢是咱们在需求阶段去确定系统边界所做的一些事情。咱们现在呢是在高层架构设计阶段，咱们现在来做确定系统边界呢，肯定是要基于需求分析阶段的确定好的系统边界，在这个基础之上来进一步的去细化。那么该做些什么呢？咱们也回顾回顾。再看看这个。已经到了高层架构设计阶段了，那么咱们要去确定系统的边界。首先呢就是这一大堆，我们要确定系统该做什么而不做什么，以及明确系统与周边系统的关系。还有呢明确系统在整个大业务场景下的定位，以及明确系统的运行环境以及前置条件。其实这里面有一部分咱们在需求分析阶段已经有了。你看明确我们的系统和周边系统的关系是不已经有了，就说我们的系统有可能是单向依赖于外部的系统，也有可能是跟外部的系统有来回的交互。就是说我们要找他要一些功能，它也需要我们去提供一些功能。这就是来回的一个交互相互依赖。

那有一些呢可能是我们依赖于外部的系统，外部系统呢不需要我们给提供任何的功能，那就变成了单向依赖等等的。那这些在需求阶段已经有了，那我们就不管了。毕竟咱们现在啊是在做高层架构的设计，也就是说已经进入到具体设计的这个阶段了。那我们更关注的就是这一部分内容，也就是需要去明确系统与相关系统的交互。明确哪些呢？我这里给大家罗列了一些就是交互方式、交互频次、交互数据量以及交互的限制和约束等等的。