目录
合适原则（Appropriateness Principle）
高并发原则（High Concurrency Principle）
高可用原则（High Availability Principle）
业务设计原则（Business Design Principle）
一、对架构与架构图的理解
（一）架构的本质
架构是一个系统或结构的基本设计。它描述了一个复杂系统中各个组成部分的组织方式、相互关系、功能和行为。架构在任何领域中都可以存在，包括软件、硬件、建筑、企业等。
- 在软件领域，架构通常指软件系统的高级结构，包括各个模块、组件和它们之间的相互作用。软件架构是在软件开发过程中的一个重要阶段，它的设计决定了系统的整体布局和逻辑，对系统的可维护性、扩展性和性能等方面都有重要影响。
- 在硬件领域，架构涉及计算机系统的设计，包括处理器、内存、存储器、总线等组件的连接和组织方式。
- 在建筑领域，架构指建筑物的设计和结构，涉及建筑的整体布局、材料选择、结构安排等方面。
总体而言，架构是指对一个系统的整体设计和组织，它为系统的功能和性能提供了基本框架，并决定了各个部分之间的关系和交互方式。
架构的本质可以理解为它由三个要素组成：要素、结构和连接。这三个要素的相互关系形成了整个系统的架构。
- 要素：指构成系统的基本元素，可以是组件、模块、功能、数据等。它们是系统的构建块，是实现功能的基本单位。
- 结构：是指将系统的要素按照一定规则或布局进行组织和排列，形成整体的结构框架。结构决定了要素之间的相互关系和协作方式。
- 连接：是指将各个要素之间建立联系和交互方式，使它们能够相互通信、传递信息和共同完成系统的功能。
综合上述三个要素，架构就是按照特定结构将系统要素连接起来，使其相互协作、互相影响，从而实现系统的整体功能和目标。
（二）软件设计中架构域的划分
在软件设计中，架构域是根据不同方面的考虑将整个系统的架构划分为不同的层次或领域。这些架构域描述了系统在不同维度上的结构和组织方式，以便更好地理解和设计软件系统。以下是对各个架构域的简要解释：
- 业务架构：业务架构关注的是软件系统的业务层面，即系统要解决的业务需求、业务流程和业务规则。它涉及如何将业务需求转化为软件系统的功能和行为，确保软件系统能够满足业务目标和需求。
- 数据架构：数据架构关注的是软件系统中数据的组织和管理方式。它包括定义数据模型、数据流、数据存储和数据访问方式，确保系统能够高效地处理和存储数据，并保证数据的一致性和安全性。
- 产品架构：产品架构着重于软件系统的功能和特性，以用户的角度来设计系统。它考虑如何将各个功能模块组织起来，提供给用户一个好用、易懂、高效的产品体验。
- 应用架构：应用架构关注的是软件系统中不同应用程序之间的关系和交互方式。它涉及到如何将系统划分为多个模块或子系统，并定义它们之间的接口和通信方式。
- 技术架构：技术架构关注的是软件系统的技术层面，包括选择合适的开发语言、开发工具、硬件平台等。它涉及到如何在技术上实现软件系统的需求，并确保系统的可靠性、可扩展性和性能。
通过将软件系统的架构划分为以上不同的域，软件设计团队可以更好地对系统进行分析、规划和实现，从而构建出功能强大、高效稳定的软件系统。
（三）架构图设计
架构图设计的必要性
如何画架构图
在架构设计过程中，架构分解是必不可少的关键步骤。如何进行架构分解，从哪里入手开始进行分解？这些需要一套架构分解的过程模型和过程方法来指导分解。
从架构域的分类：业务架构、数据架构、产品架构、应用架构、技术架构这 5 个域，依次需要进行架构分解。每个结构域的分解过程，都是一个迭代过程。从无到有、从粗到细、从模糊到清晰，一步步精细化、丰富架构。迭代的过程就是一个否定之否定的过程，随着分解的逐步推进或系统的架构演化，后面的分解除了会识别出新的架构元素，也可能会对先前识别出的架构作出调整。整个架构分解的迭代过程，通过画架构图的方式是种非常直观的表现形式。
二、实践业务架构与产品架构设计
在业务域的分解过程中，从系统需求出发可能只得到模糊的描述，但确实是一个很好的起点。
针对模糊的需求，合理的做法是先将问题域列清楚，进行深入的问题探究和领域分析。这样可以更好地理解业务场景和需求，从而有助于后续的架构设计和功能规划。以下是一些可行的步骤来进行业务域的分解和问题探究：
- 问题探究：与相关利益相关者进行深入的交流，包括老板、运营、用户等，了解他们的需求和期望。主动提问，澄清需求，探究背后的问题和目标。
- 场景分析：分析涉及的业务场景，了解业务流程和相关环节，探索问题域中的各种活动和角色。
- 需求收集：收集来自各方的需求，并将其整理成清晰的需求文档。在整理过程中，逐步细化和明确需求，确保问题域的范围清楚。
- 需求优先级：将收集到的需求进行优先级排序，确保核心问题得到重点关注。
- 问题域划分：将问题域分解成相关的子域，从宏观角度进行归类和分类。可以使用流程图、用例图或其他合适的方式来描述问题域。
- 领域模型：根据问题域的划分，创建领域模型来表示问题域中的实体、属性和关系。领域模型有助于更好地理解业务场景和问题。
- 进一步细化：针对每个子域，进一步细化和明确需求，探究可能的解决方案和业务流程。
- 沟通和确认：与利益相关者进行沟通和确认，确保他们对问题域和需求的理解一致，并不断反馈优化。
通过以上步骤，您可以逐步将模糊的需求转化为清晰的问题域，为后续的架构设计和功能规划提供更好的基础。这样的分解过程有助于确保您在架构设计中不会忽略重要的业务场景和需求。
最终一种好的产品架构图，应该具备以下特点：
- 清晰的模块功能边界
- 功能经过抽象，做到标准化、互相独立
- 上下游产品功能边界清晰，架构分层明确合理，具备迭代优化的能力
以风控系统为基础简单展开分析。
（一）列出问题域
问题域，是指自己的产品能够解决的所有问题的空间集合。从核心需求出发，将所有当前需要解决、未来可能需要解决的问题放入产品框架的范围，能够帮助你的产品架构拥有更高的可拓展性，在后续具备迭代和优化空间。风控系统的问题域展示如下：
详细的操作步骤：
- 找到收到的需求中，跟产品形态、产品目标相关的语句，去列出“xx 的流程会是什么样”、“xx 该如何达成”之类的问题，直到如果这些问题解决，能够实现核心需求的方向和业务目标。
- 去逐次寻找这些问题需求被解决的过程中，是否有其他要先解决掉的问题、或者其他跟业务相关的问题能够被解决。
- 按照层级去罗列所有的问题，并附上自己的初步回答，从而形成一个初步的、自己的产品能够解决的“问题域”。
（二）确定产品方向
在经过问题域的罗列后，能够得到一个模糊的产品方向和功能范围。问题域的环节非常发散，这一步需要回归基础，把模糊的需求补充、拓展和翻译成一个能够在商业模式和用户体验能够形成闭环的产品需求。以风控系统需求为例，产品方向的描述如下：
在确定产品方向这个环节的详细操作步骤：
- 产品用户：需要明确产品定位的用户，解决核心用户的核心需求。
- 核心目标：思考清楚自己产品的核心目标是什么。如果以一个 KPI 指标衡量产品的价值，那这个 KPI 应该是什么。
- 依赖系统：自己的系统需要与哪些外部系统存在交互和关联关系，我们的系统在这个大的生态下，是什么定位。
（三）绘制业务流程和矩阵
通过对业务流程进行分析，根据功能职责，进行垂直分解，识别出业务功能和业务服务，将他们归类到相应的流程节点中去。将业务流程和业务功能点组合成一张业务功能矩阵。这张矩阵图是业务架构中为后续的数据架构、产品架构、技术架构作为重要的输入。
（四）功能架构分层
产品框架脱胎于业务流程，但相比业务流程，更加注重产品功能的枚举、功能模块之间的分界。以业务架构的业务功能矩阵图作为输入，将流程图转换成按节点进行分层，节点的功能点存放在同一层中。
在此基础上将明显是同一个产品范围、同一组产品功能的模块放在同一层级，得到一个基础的产品框架。
（五）明确功能边界
一个具备前后台关系的产品架构图至少分三层：用户感知层（在何种场景下通过何种方式触达用户）、功能模块层（通过哪些功能模块实现产品的核心功能、和哪些外部平台功能有信息交互）、数据层（产品的数据从哪里来、产品的数据沉淀到哪里去）。
在上一步进行简单分层后，已经得到一个初步框架，但是难免会有分层不明确的问题。此时需要按照两种维度来处理架构图的层级：不同信息层级的边界、同一层级内模块和模块的边界。
处理不同信息层级的边界
架构图的层级表达其实是信息之间的流转关系，不同信息层级之间一定是有逻辑关系的。其中用户感知层和数据层通常化简为以（用户端的功能表达往往逻辑简单、数据来源问题则不是自己产品的核心功能），而功能模块则需要按照自己产品的逻辑去将功能模块层内的主要模块变成新的层级。
处理同一层级内子模块的边界
各层次之间虽有相关，但同一层次内的子模块之间一定是相互独立、界限分明的。将解决不同问题的功能拆分成两个子模块，做到一个问题只在同一层解决，避免牵一发而动全身的情况出现。
（六）明确系统间边界
产品边界对于开发设计系统架构、业务间的合作模式都非常重要。在架构图中用不同颜色标识清楚，各个部分所属系统的边界。通常属于自己团队的部分用亮色标识。像外部系统，如数据层的用暗色标识。
（七）加入信息流
产品架构图在表达产品的核心功能外，也应该体现信息流动的路径。当前层级数据的交互形成产品功能，产品功能又产生新的数据，从而推动下一层级的功能运转起来。
如果当前产品的主要使用角色只有一个，则只需要用箭头表明模块间信息流动的方式即可。如果当前产品涉及的角色比较多，则需要用不用颜色的线条将他们和各个模块之间的信息交互关系表示出来。
三、从领域模型提取数据架构
一种好的 ER 图需要具备以下原则：
- 同一实体在同一个 ER 图中只能出现一次
- 先设计局部 ER 图，再把每一个局部 ER 图综合起来，生成总体的 ER 图。
数据架构重要的输出是数据-实体关系图，简称 ER 图（包含了实体数据对象、关系和属性 3 种基本成分）。建立准确的数据模型需要从业务架构出发，对业务域进行领域建模分析，并逐步提取数据架构图（ER 图）。以下是一个基本的步骤来建立产品的数据模型：
- 了解业务需求：从业务架构出发，深入了解业务需求和场景。与相关利益相关者沟通，澄清业务规则、流程和数据对象。
- 领域建模：使用领域建模技术，将业务需求转化为领域模型。领域模型描述了业务领域中的实体、属性、关系和业务规则。
- 识别实体和属性：在领域模型中识别实体（数据对象）和它们的属性。实体是系统中需要存储的数据对象，属性是实体的特征。
- 定义关系：确定实体之间的关系。关系描述了实体之间的联系和依赖关系。例如，一对多、多对多等关系。
- 绘制ER图：根据领域模型中的实体、属性和关系，绘制ER图。ER图使用图形符号表示实体、属性和关系，可视化系统的数据结构。
- 规范化：对数据模型进行规范化，确保数据的冗余最小化、数据一致性和可维护性。
- 验证和优化：与利益相关者一起验证数据模型的准确性和完整性，并根据反馈进行优化和调整。
- 持续演进：随着业务需求的变化，数据模型需要持续演进和改进。确保数据模型与业务的一致性和匹配度。
说到领域模型，可采用四色原型法进行业务模型的抽象。在进行四色模型分析前，先了解下四色模型的一些基本概念。
四色模型，顾名思义是通过四种不同颜色代表四种不同的原型。
- Moment-Interval Archetype 时标性原型：表示事物在某个时刻或某一段时间内发生的。使用红色表示，简写为 MI.
- Part-Place-Thing Archetype 参与方-地点-物品原型：表示参与扮演不同角色的人或事物。使用绿色表示。简写为 PPT。
- Role Archetype 角色原型：角色是一种参与方式，它由人或组织机构、地点或物品来承担。使用黄色表示。简写为 Role。
- Description Archetype 描述原型：表示资料类型的资源，它可以被其它原型反复使用，并为其它原型提供行为。使用蓝色表示。简写为 DESC。
还是以风控系统为例，进行领域建模的过程如下：
（一）关键流程
在进行业务建模前，首先需要梳理出业务的流程，这一步在业务架构分解环节中已经完成。按照四色建模法的原则，将业务流程图进行一点改造。在原来的流程图上，将流程涉及的事务和角色添加进来。
（二）领域模型骨干
从业务流中，可以清晰的定义出 Moment-Interval Archetype （时标性原型），流程中的每个节点符合 MI 的定义，即事物在某个时间段内发生。
在 MI 的定义过程中，一种方法是通过名词+动词进行定义。
风控的 MI 即为：数据采集、规则 &模型设置、风险识别、告警通知、风险处置、风险分析（MI 使用红色表示）。
在得到骨干之后丰富这个模型，使它可以更好的描述业务概念。这里需要补充一些实体对象，通常实体对象包括：参与方、地点、物（party/place/thing）。
Part-Place-Thing Archetype（参与方-地点-物品原型）：业务对象、规则、模型、异常风险、通知、异常事件、分析报告（PPT 使用绿色表示）。
领域模型骨干图，如下：
（三）领域模型角色
在领域模型骨干的基础上，需要把参与的角色（role）带进来。Role 使用黄色表示。如下图：
（四）领域模型描述
最后将模型的描述信息添加进来，模型的描述信息中涵盖模型的具体属性。这些描述信息对于后面数据库设计有很大的影响。模型描述使用蓝色标注，如下图：
（五）提取 ER 图
领域模型构建完成之后，在此基础上，我们已经能够初步的掌握整个系统的数据模型。其中绿色的 Part-Place-Thing Archetype（参与方-地点-物品原型），可以用来表示 ER 图中的实体模型。红色的 Moment-Interval Archetype（时标性原型），可以用来表示 ER 图中的关系。对领域模型架构图进行提炼，得到如下图：
实体（Entity）和联系（RelationShip）存在一定的关联关系，一般存在 3 种约束性关系： 一对一约束、一对多约束和多对多约束。将这些约束性关系表现在 ER 图中，用于展现实体与实体间具体的关联关系，最终输出 ER 图。（考虑保证 ER 的简洁性，这里并没有把模型的属性画进来）
四、单体式与分布式的应用架构
应用架构分为两种：一种是单体式应用架构、一种是分布式应用架构。
单体式应用架构
单体式应用架构是传统的应用架构模式，整个应用由一个单一的应用程序组成，所有功能模块和组件都集中在一个代码库中。数据存储通常在一个数据库或存储介质中。这种架构通常是较小规模的应用，适用于简单的业务需求和小团队开发。
分布式应用架构
分布式应用架构是指将系统拆分成多个独立的子系统，这些子系统可以部署在不同的服务器上，并通过接口的方式进行通信和协作。每个子系统有自己的数据存储，通常存在多个数据库或数据存储介质。
| 优点 | 缺点 | |
| 单体式应用架构 |
|
|
| 分布式应用架构 |
|
|
总体而言，单体式应用架构适用于较小规模和简单业务的应用，开发和维护相对简单。而分布式应用架构适用于复杂业务和大规模系统，具备更好的扩展性和故障隔离性，但需要处理复杂性和一致性等挑战。根据业务需求和规模选择合适的架构是关键。
（一）划分应用
在产品架构这个架构域，通过按照模块之间的聚合和分层，逐步形成产品内部子系统的边界。按照子系统的边界进行切分，能得到整个产品的子系统组成如上第二部分第（七）终图。
应用架构的分解，通过对产品架构按照水平和垂直两个维度进行划分。
水平划分
在产品架构的环节，按照同一产品范围的模块放在同一层级的原则，得到水平层面的应用系统划分。只要产品架构明确定义了系统间的边界，很容易确定整个产品的各个子系统。
垂直划分
当应用内存在几个相对独立的模块，每个模块的业务逻辑差别比较大，且内部的组成较为复杂和庞大时，还需要进一步对应用内进行子系统的切分。这里的切分原则是，对应用内按业务进行切分，保证子应用是相互独立。
比如风控系统的案例中，在风控引擎这个应用中，存在实时、离线的校验场景。每种场景都是相对独立。这时候将这三个模块按照子系统进行切分成：实时风控引擎子系统、离线风控引擎子系统。
（二）单体式应用
单体式应用架构通常可以分为数据层（Data Layer）、应用逻辑层（Business Layer）、表现层（Presentation Layer）和基础通用层（Common Layer）这四个层次。
下面将对每个层次进行展开分析：
- 数据层（Data Layer）：数据层是负责处理数据的存储和访问的层次。它包括数据库或其他数据存储介质，用于持久化存储数据。在这一层中，可能会定义数据库表、视图、存储过程、触发器等数据库对象，用于实现数据的增删改查操作。数据层的主要职责是管理数据的存储和读写，确保数据的安全性和一致性。
- 应用逻辑层（Business Layer）：应用逻辑层是处理业务逻辑和规则的层次。在这一层中，会定义应用程序的业务逻辑，处理业务需求和规则。它负责对来自表现层的请求进行处理，调用数据层进行数据读写，并返回处理结果。应用逻辑层不涉及具体的数据存储细节，而是专注于处理业务逻辑，确保系统的业务功能正确执行。
- 表现层（Presentation Layer）：表现层是与用户交互的层次。它包括用户界面和用户输入处理。在这一层中，定义用户界面的设计和展示，接收用户的输入请求，并将其传递给应用逻辑层进行处理。表现层的主要职责是向用户呈现信息，并接受用户的操作。
- 基础通用层（Common Layer）：基础通用层是提供通用功能和工具的层次。它包括一些公共的模块、类、库等，用于提供系统中常用的功能。这些功能可能被多个层次共享，例如日志记录、认证授权、异常处理等。基础通用层的主要职责是提供通用功能的封装和复用，降低系统的重复性和复杂性。
以上四个层次构成了单体式应用架构的基本组成部分。每个层次有着独立的职责和功能，它们协同工作来实现整个应用的功能和目标。这种架构模式在小规模和简单业务的应用中较为常见，但随着应用规模的增大和业务的复杂性增加，可能会面临扩展性和可维护性等挑战。在这种情况下，可能需要考虑使用更为灵活的分布式应用架构。
按照上述的方式，我们得到风控系统中的子系统：处置中心系统的单体应用架构。如下图：
（三）分布式应用
分布式应用架构图实质是产品内部所有应用在分布式环境下的调用关系图。各应用间通过服务的形式相互调用，这是典型的 SOA 架构。在应用架构图中，SOA 架构中的服务注册、服务治理、服务发现这些 RPC 框架的基础平台功能不用在应用架构中体现。
应用架构图的重点是体现应用之间的逻辑关系和通信关系，体现产品的内部关系和外部关系。内部关系是产品内各应用的调用关系；外部关系展现的是产品与外部系统间的调用关系。将应用的内外关系呈现在应用架构中，产品在整个业务中的定位和影响将变得清晰。
应用间调用关系
在产品内部的各子系统之间，为了解决业务需求，通过应用之间的服务调用或者异步消息调用产生数据关系。通过产品架构图中得到的应用系统划分，按照系统间的调用关系，形成内部应用的集成架构图。在应用集成架构图中，需要标注调用链路中的业务含义，清楚的标注应用之间发生的业务关系。
外部系统调用关系
数据输入做为产品的业务数据来源，很大部分是外部系统提供。在应用架构图中，按照业务属性、来源关系进行对外部系统进行归类，并将外部的来源系统纳入整个应用架构中。我们知道计算机系统中，数据输入和数据输出是作为一个整体。应用架构中除了输入系统，输出系统做为整个产品的一部分，需要纳入到应用架构图中。
外部系统调用关系
数据输入做为产品的业务数据来源，很大部分是外部系统提供。在应用架构图中，按照业务属性、来源关系进行对外部系统进行归类，并将外部的来源系统纳入整个应用架构中。我们知道计算机系统中，数据输入和数据输出是作为一个整体。应用架构中除了输入系统，输出系统做为整个产品的一部分，需要纳入到应用架构图中。
最终一种好的应用架构图，应该具备以下特点：
- 清晰的应用边界。
- 应用之间的调用关系明确。
- 有入必有出，有输入系统、必有输出系统。
- 清晰的呈现应用的全局关系。
五、技术架构的战略和战术原则
业务在千变万化、技术在层出不穷，没有一套通用的技术架构模式来适用所有的系统。那么，我们如何保证在做技术架构时，能够实现一个稳定、出色的系统。面对这些“不确定性”时的架构设计问题，这里从战略和战术两个层面来提供一些设计原则。战略层提供的是技术架构的方法和思路，属于顶层设计；战术层提供的是技术架构的技术实践方式，更偏向详细设计。
（一）战略层设计原则
战略层的设计原则可以简洁地概括为三个主要原则：合适原则、简单原则和演化原则。
合适原则（Appropriateness Principle）
合适原则指的是在进行技术架构设计时，选择合适的技术和解决方案来满足系统的需求。不要盲目地追求新技术或流行技术，而是根据实际需求和业务特点，选择最适合的技术和工具。考虑到系统的规模、性能、可靠性和安全性等方面的因素，做出明智的技术选择。
简单原则（Simplicity Principle）
简单原则强调在技术架构设计中保持简洁性和可理解性。避免过度设计和复杂性，保持架构的简单和直观，使其易于理解、维护和优化。简单的架构更容易被团队成员理解和掌握，降低系统的开发和维护成本。
演化原则（Evolutionary Principle）
演化原则指的是设计架构时考虑系统的演进和变化。系统的需求和业务环境会不断变化，架构应该具备足够的灵活性和可演进性，使其能够适应未来的变化和需求。避免过度耦合和紧密绑定，将系统拆分为独立的模块和组件，使其可以独立演进和扩展。
这三个战略层的设计原则提供了架构设计的方法和思路，帮助保证系统能够在不确定的业务和技术环境中实现稳定、高效和优良的性能。在架构设计过程中，合理运用这些原则，可以确保技术决策的合理性和系统的长期成功。
（二）战术层设计原则
战术层的设计原则确实可以分为三个重要部分：高并发原则、高可用原则和业务设计原则。
高并发原则（High Concurrency Principle）
高并发原则强调在设计架构时考虑系统需要支持高并发请求。对于大规模系统或面临高并发访问的场景，需要选择适合的技术和架构方案来确保系统能够有效地处理大量并发请求。这可能涉及到采用分布式架构、缓存技术、异步处理等手段，以提高系统的并发处理能力。
高可用原则（High Availability Principle）
高可用原则指的是确保系统在面对故障或意外情况时能够保持可用性。为了实现高可用性，需要选择具有冗余和故障恢复能力的技术和架构。例如，使用负载均衡和故障转移技术，确保系统在一台服务器出现故障时能够无缝切换到其他服务器，保持服务的可用性。
业务设计原则（Business Design Principle）
业务设计原则强调在技术架构设计中紧密关注业务需求和业务逻辑。架构设计应该紧密地与业务逻辑相匹配，确保系统能够正确、高效地执行业务功能。这可能涉及到采用合适的设计模式和最佳实践，以实现系统的可维护性和可扩展性。
通过遵循这些战术层的设计原则，可以在技术架构设计过程中更加准确地选择和使用技术，确保系统满足高并发、高可用性的要求，同时与业务需求紧密匹配。
（三）技术架构图
技术架构图是将系统的技术方案、技术选型通过视图的方式进行展现。技术架构图分为两类：一类，功能需求技术架构图（逻辑架构图），是描绘如何通过技术组件来实现系统产品功能的图。另一来，非功能需求技术架构图（物理架构图），是描绘如何通过物理部署的来实现系统运行的图。
逻辑架构图
功能需求技术架构图以产品架构图和应用架构图为基础。实现每个功能点需要使用什么技术、技术实现逻辑如何，就提现在技术架构图上。功能需要技术架构图绘制可以按照“整体 -局部 -整体”的思路实现。
整体
首先可以按照应用架构图的应用分布得到应用分布框架。如下：
局部
在整体框架的基础上，对每一个局部的子系统进行详细的技术实现的表达。子系统的技术架构图中需要展示每个子系统使用的技术组件，比如（缓存技术、消息中间件、流程引擎、流式计算框架等等）。同时，这些技术组件是如何实现业务功能，需要清晰的展示技术实现逻辑。下图是对风控系统中的实时引擎、离线引擎、准实时引擎三个子系统的进行的技术架构。
在实时引擎中，主要使用 RuleEngine（规则引擎）作为技术特点，这里就重点列出 RuleEngine。准实时引擎使用 Blink 作为流计算的技术框架，并概要的展示了计算逻辑。
整体
在完成每个子系统的技术实现后，最终进行一次整合，绘制一张总体的系统技术架构图。各子系统之间通过服务接口、数据库、缓存或消息中间等技术实现数据交互，以此将打通各个子系统，实现最终整个产品从数据、技术的串联。
物理架构图
物理架构偏重于网络设计、集群设计、中间件设计、数据存储设计等基础软硬件的设计架构。非功能需求的技术架构图重点在于展示企业系统在物理上是如何部署。物理架构规定了组成系统的物理元素、物理元素之间的关系以及他们的部署策略。物理架构反映出软件系统动态运行时的组织情况。从物理架构图中，我们能够全局的得知整个系统是如何从流量访问、数据流转、数据存储到技术组件的运转。
参考文章和链接说明
- 《架构设计实践五部曲》，胡斌，菜鸟网络技术专家，目前负责菜鸟风控系统的建设。曾在淘宝技术部先后负责卖家平台、商家运营等领域。在大规模分布式应用、大数据、架构领域有多年的开发和管理经验。主要来自该部分，架构设计实践五部曲（一）：架构与架构图_架构_胡斌_InfoQ精选文章
- "A Note on Distributed Computing" (Leslie Lamport)- 这篇论文提出了分布式系统中的一致性问题，并引入了Lamport时钟的概念。这是分布式系统中的经典问题之一，对分布式架构的理解有很大帮助。
- "Microservices: A Definition of This New Architectural Term" (Martin Fowler) - 这篇文章由Martin Fowler撰写，定义了微服务架构的概念。它对微服务架构的特点、优势和挑战进行了解释，对现代软件架构设计有重要影响。
- "No Silver Bullet: Essence and Accidents of Software Engineering" (Frederick P. Brooks Jr.) - 这是一篇经典的软件工程论文，指出了没有单一的解决方案可以解决所有软件工程问题，对软件架构设计的思考和实践提供了深刻的洞察。
- "The Design of Design: Essays from a Computer Scientist" (Frederick P. Brooks Jr.) - 这本书收录了Frederick P. Brooks Jr.的多篇论文，涵盖了软件设计和架构方面的话题，对设计原则和实践进行了深入讨论。
- "The Fallacies of Distributed Computing Explained" (Peter Deutsch) - 这篇文章介绍了分布式计算中常见的谬论，对分布式系统的设计和分析有很大启示。
- "On the Criteria to Be Used in Decomposing Systems into Modules" (David L. Parnas) - 这是一篇经典的模块化设计论文，提出了模块化设计的原则和准则，对软件系统的设计和架构分解提供了重要指导。
- "The Mythical Man-Month: Essays on Software Engineering" (Frederick P. Brooks Jr.)- 这本书是软件工程领域的经典之作，涵盖了软件项目管理、架构和设计等多方面的主题，对软件架构师和设计师有很大启发。