前言

在工作中，我们经常需要进行前端的架构设计以满足各种系统需求。在学习 DDD（领域驱动设计）之后，我深受启发，于是不断地在各种系统需求中进行实践并归类。本文将尝试总结各种需求的架构经验和模式，以此为基石，指导并提升我的工作方法。

本文由总到分，由粗到细，解释了作者眼中架构的由来发展到具体的设计经验。

架构前言浅谈

架构存在的意义？

我们世界的本质就是由信息组成的，我们很有可能生活在虚拟世界中。在人类创造的事物中，一切都围绕着人类的基本欲望进行创造和发展。因此我认为，软件和架构的本质是对人做事进行管理的系统工程。当人做事时遇到违反预期、违反欲望的阻碍时，在架构和产品上就会进行优化解决。

所以分析架构和建设架构需要从系统各方的需求出发。

架构的发展？

根据上述观点，架构的发展是为了满足人类的期望。在一个系统中，有不同角色的人参与，他们有不同的需求。在动态平衡的状态下，就形成了一个平衡的架构。因此，架构可以被描述为"角色（人）+产物（满足不同角色的人的需求）"。因此，架构的发展可以被看作是动态平衡的演变，根据各种趋势可以预见架构的演变。

例如，系统的使用方要求实现万物互联，因此系统架构朝着微内核、高扩展性的方向演变。而该内核的内容就是实现万物互联的基本要素，即网络库和操作系统内核相关的代码。不同需要联网的电子产品，在该内核的基础上，再组合所需的库或插件，完成整体的联网功能和自己领域的功能。

对于人们日益增长的需求，人与系统之间的数据传输速率需要越来越快，从系统中获得的信息质量也需要越来越好，因此才会有文字→图片→视频→3D→脑机接口的发展历程。每一次迭代都极大地提高了人与系统交互的带宽。

架构的基础抽象

根据上面的说法，架构的基础抽象就是角色 + 系统（不同角色需求平衡下的产物）。再细化一点，软件中有消费者、生产者、开发者，这些基本角色。

对于消费者和生产者，他们直接操作的可能就是UI界面，这部分涉及到产品架构，由开发者中的PM、UX来构建，这个领域内，如何理解和满足用户需求是最重要和基础的。但是不在本文讨论范围内。

对于开发者角色中，研发是直接构建和实现UI以及数据存储的人群，本文旨在讨论这部分的内容。

所以先有用户需求，产生PM视角的产品架构，然后研发再由产品架构，产生技术架构。提问：产品架构还会产生什么领域的架构？

组织架构
数据架构：确定如何组织、存储、管理和保护数据。
安全架构：确保产品的安全性，包括身份验证、授权、加密和其他安全机制。
网络架构：涉及产品的网络通信，包括服务器、负载均衡器、网络拓扑等。
股权架构
合规架构：确保产品遵守相关法律法规和标准。
营销架构：营销策略与产品架构的协同，确保市场定位和推广效果。
...

总之架构的本质其实还是人的组织，人的不同组织架构会影响不同的领域架构。比如人事组织架构会影响产品架构，或者产品架构也可以影响组织架构。我们从不同公司的组织架构都可以映射到他们的产品架构。

技术架构的范围

我们从基础抽象中得知，技术架构是由产品架构产生的。一个产品的实现需要满足基本需求，包括运行时、产物和数据。

作为项目经理（PM），需要定义产品的运行状态和信息需求。研发团队则负责将产品架构转化为系统、数据，并进行部署和维护，使其能够在运行时正常使用。用户直接使用的是运行中的系统。

因此，我们在技术架构讨论中关注的领域包括：如何组织和编写我们的产物、如何维护我们的运行时、以及如何定义数据的生产、消费和存储协议。

技术架构的设计目标

需适应产品架构的演进

技术架构需要适应产品架构的演进，这是最基本的一点。例如，能够以更低的成本快速进行产品迭代，或者支持承载超大用户流量等。

在设计技术架构时，我们的起点是产品的架构。除了基本实现产品的架构，还需要考虑架构能否随着产品架构的演变而变化。可以从人的几个维度来解释产品的基本演变趋势。根据之前提到的架构基本抽象和角色，我们可以得出以下几点：

产品使用者规模和角色：用户规模的趋势和用户需求的演变，为了满足用户需求和优化维护运行时的稳定，我们需要对整个系统的架构进行调整。例如，从最初的抖音到剪映、单机房到多机房等。
开发者规模和角色：随着系统的扩大，开发者数量也会增加，需要提高开发效率，因此也需要进行调整。例如，从最初的大服务到微服务。

技术架构的设计思路

功能模块设计：先粗后细，再由细到粗

功能模块是对产品运行时各个系统的抽象划分。

这块我直接按照DDD的领域建模流程来说明：

首先，需要根据产品架构，梳理出大概的模块。

业务产品研发，根据PRD、用例、获得对产品的认知。

例如：

我们提供一个开放平台，提供如下功能

然后，梳理事件风暴，梳理出产品的业务模块（每个模块维护的人数不超过"两个披萨团队"。"两个披萨团队"得名的由来，是因为团队的成员很少，只有6-10人，用两个披萨就能喂饱他们。"两个披萨团队"最重要的不是规模，而是它的"适度职责"。）。
1. 事物出发为事件点，我们基于对业务的主观了解，先列出一系列业务的状态、参与者、系统等，他们刚开始是无序的。

markdown 复制代码

1.  点成线：可以将业务状态和事件链接归类为不同的领域事件和参与者，进行初步的分类。

markdown 复制代码

1.  线生面：务状态和事件有各种组合，在业务逻辑下，我们推演、组成了各种领域事件发生过程：**触发参与者、命令、事件、结果状态。**如下面事件风暴的图

根据事件风暴梳理领域实体图

最后根据领域实体图得到总体的业务领域模块设计和其依赖

上面的流程演示了一个DDD的对系统建模的流程，它主要明确了运行时的功能模块设计，这部分架构是和产品架构强相关的，也是后面几种架构的基础。

可以想想为什么是强相关？产品架构往往指向系统运行时各种模块的交互逻辑，而此技术架构也是描述的系统运行时的模块关系，所以是和产品架构直接相关的。

需要注意的是，DDD架构不一定适用于所有项目，在功能模块的设计中，我们主要能根据复杂度，得出团队内认可的模块图就可以，不一定需要走事件风暴等比较耗时的流程。

代码模块设计：打横还是打竖

代码模块设计是对静态文件的结构设计。

为什么要对代码文件结构进行设计？ 其本质原因是代码更改的合作流程，也就是GIT，我们将维护一个模块所需修改的文件范围缩的越小，上下文越集中，越能有助于我们快速安全的进行代码迭代。

为什么要打横和打竖？

打横就是分层。对于事物发展过程，我们可以以不变和变来划分，不变的部分会固化，变化的部分会流动。比如大浪淘沙，轻沙子跟着水流动，重沙子沉底筑基。同时可以类比自然界的发展过程，水流可以冲刷基地改变固化的河道。我们的模块设计也是需要遵循类似这样的自然的过程。

因此，打横就是类似于泥沙沉底分层的过程，也就是隔离变化快的部分和不快的部分，这样可以提高总体系统的可维护性和稳定性。

在软件系统中，变化慢的大概有工具层、领域层、变化快的有适配层和应用层，我们将核心的变化慢的放内层，变化快的放在外层，这样就有了DDD的层级架构。这里面有个原则，就是外层只能单向依赖内层，内层不能依赖外层。否则就失去了分层的意义。

打竖就是分业务功能模块，在只打横的基础上，我们的各种业务模块如果都放在一起，则可能面临分工不明确、文件太臃肿的问题，所以在分层的同时，也需要对太臃肿的模块进行打竖，以进一步提高可维护性。但是如果只打竖的话，则就没法很好的隔离变化，使得系统有更好的扩展性。

所以总的来说，我们当需要隔离变化和整治依赖的时候需要进行分层 ，当需要更好的分工的时候需要打竖。需要注意的是打横还是打竖是分不同情况来设计的，不能按照一个静态的模板来设计。

如何进行设计：

对于一个系统来说，运行时的接口或者UI，对应不同的模块，这个模块有多深就是它涉及的层级，有多宽就是它在层内的涉及的文件有多少。

在设计系统时，我们可以从横向和竖向两种思路进行设计，如果我们的系统对外部变化很灵活，变化速度快，则我们应以横向进行切入，优先隔离变化，进行分层设计。而竖向的设计思路比较简单，可以单纯分模块分接口分服务，都可以分出来。比较难的一点是分多少层，一层有多厚？

在上述的功能模块设计中，我们明确了系统的领域范围和领域模块，接下来我们可以全面审视所有模块的深度，并根据变化和不变的原则进行分层切割。以常见的前端架构为例（以下架构分析仅为推测）：

当我们实现一个 UI 页面时，前端会将其拆分为多个组件模块。以抖音的前端架构为例，我们可以按照入口组件向下划分，包括组件、逻辑和基建交互。然后，我们可以横向划分，根据变化度进行隔离，将每个模块划分为基建层、逻辑层和视图层。逻辑层和视图层用虚线表示，因为我们不一定按照层级将竖向的模块拆分到各个层中，而是根据是否是通用的组件或逻辑来考虑进行分层。至此，整个页面的分层和模块结构已经清晰明了。也有一些模块比较浅显或通用，比如按钮模块。实线会导致模块被文件实际分割，比如基建层不包含在模块文件夹下，而是基建层文件夹下。

我们在设计中遵循的一个原则是尽量简化业务，分层尽量少。因为如果分层太多，会导致模块过于破碎，增加了上下文的复杂性，从而降低业务开发效率。我们可以看到，每个模块层之间基本没有耦合，也就是说每个模块相对独立，那么其实可以合并为模块层和通用层即可。如果每个模块中都依赖一些通用的业务逻辑，则可以考虑将这些逻辑抽离出来形成一个独立的层。总之，抽层的本质就是隔离变化。

后续我们按照横竖分文件夹，需要注意的是，我们需要按照前端团队熟悉的范式进行名称设计，否则会导致上下文同步效率低下，使得成员无法顺利交接和融入架构。横向设计提现在文件树顶部层级，竖向体现在文件树叶子结点部。

这个架构适合大部分前端页面的架构，对于微前端来说，模块层可以是 pages 或者 apps，我们可以简单直接地按照模块和通用进行分层，模块内部再进行分层。由于大部分前端页面的模块都是相对独立的，因此对于系统的发展来说，就是对页面模块的维护。这样的架构将更改的文件范围集中在模块范围内。如果强行按照视图层和逻辑层对模块进行实际分割，那么模块的上下文也会被文件分割，反而会影响维护。

再举个需要分层的例子：一个低代码前端项目至于插件系统

在一个基本的低码编辑器中，由可视化编辑器、物料库、属性面板、逻辑面板构成，我们单纯按照模块依赖来看，各个模块之间有相互依赖的时候， 那就是需要分层的意思了，我们将公共依赖往下沉，设计核心层，为Schema编辑逻辑和物料资料的使用逻辑等。通过分层，这样就解决了依赖混乱的问题，外层统一依赖内层。

后续业务演变，我们发现各个模块之间对不同模块加载的时序有依赖，比如属性面板模块必须要等编辑器模块和物料模块加载好后再加载，否则无法拿到选中的物料的属性数据。这种也属于相互依赖，我们都考虑做一些能力到内层。比如我们可以将这些功能作为插件，然后做一个插件管理器，来管理顺序，同时也带来了可插拔的特性。

解决和维护依赖分层的常用手段：

依赖倒置：这是一种软件设计原则，其中高层模块不应该依赖于底层模块，而是应该依赖于抽象接口。这有助于减少模块之间的耦合，并使代码更易于测试和维护。

依赖注入：这是一种将依赖项（例如服务、数据访问对象等）注入到应用程序中的技术。这有助于提高代码的可维护性和可测试性，并使应用程序更易于扩展。
服务定位器模式：这是一种用于在应用程序中定位和获取服务的模式。服务定位器模式将服务的创建和使用分开，从而使应用程序更易于扩展和维护。
控制反转：这是一种将应用程序的控制逻辑从具体的实现中分离出来的技术。通过使用控制反转，应用程序可以更容易地适应不同的需求和环境。
抽象工厂模式：这是一种用于创建不同类型对象的工厂模式。抽象工厂模式将对象的创建和使用分开，从而使应用程序更易于扩展和维护。
外观模式：这是一种用于简化复杂系统的模式。外观模式提供了一个单一的接口来访问系统的不同部分，从而使系统更易于使用和理解。
策略模式：这是一种用于封装不同算法或行为的模式。策略模式将算法的实现和使用分开，从而使应用程序更易于扩展和维护。
桥接模式：这是一种用于将抽象类和具体类分离的模式。桥接模式将抽象类的实现和使用分开，从而使应用程序更易于扩展和维护。
观察者模式：这是一种用于通知对象更改的模式。观察者模式允许对象在发生更改时向其他对象发送通知，从而使应用程序更具灵活性和可扩展性。
命令模式：这是一种用于封装命令的模式。命令模式将命令的执行和使用分开，从而使应用程序更易于扩展和维护。

这些模块也就是插件层了，经常迭代的插件能力也被分层隔离其中。往往当核心大改的时候，这个产品也会整体改变。同时可以预见到，物料和插件是经常变化的，所以对于物料模块内肯定也会有其核心层和适配层以适应环境。

再举个微服务的例子，为什么微服务要做六边形架构，我们运行的程序要实现其稳定性，需要隔离外部经常变化的环境，比如数据库连接方式发生变动、上下游服务变更等，所以最基础的就是将这种和外界交互的东西分层出去，也就形成了六边形架构。将外界交互的部分在适配器实现，然后适配器就是将外界的信息映射为自己领域内。

以CQRS举例，一个业务系统经常读多写少的时候，如果每次新增读操作，都需要被层硬性分割的话，则使得构建一个读请求变得繁琐。所以我们才打竖，将读写的架构分离，得到读架构和写架构，经常写后端同学都知道，读逻辑比写逻辑少考虑很多东西，所以读架构也会比写架构自然的少了一些领域逻辑的校验和构造，提高了写逻辑的开发效率。这也是当层级影响了扩展和维护效率的时候，进行打竖的实践。

所以在明显的可以预见的快速变化的模块，互相依赖的模块，则可以分层，将变化和依赖隔离。不然，我们可以先按照模块打竖之后，再分层，这样可以让模块设计尽量的简单。在发现某个被层级强行分割的领域或者模块，需要经常维护或者变更的时候，再进行打竖，提高这个模块的开发维护效率。

所以模块设计的哲学，就是研究如何打竖还是打横，精确的隔离出变化域，提高总体的维护开发效率。

数据流模型设计：数据是怎么流转的

数据流模型设计是对运行时数据流转过程进行设计

我们往往使用流程图、时序图来描述数据是如何流转的，我们功能模块设计后，就需要设计数据是怎么在各个功能模块之间流转的，否则这个系统就没有血液流动，没法跑。同时得保持血液健康，没有异常数据流或者流量爆炸等情况。

在设计数据流过程中，我们经常需要注意几点：

性能：

数据是否精简
频次是否过高

稳定：

注意幂等
数据校验
流量异常
容错

维护：

可读性
可扩展

监控：

可发现异常数据和性能瓶颈
日志系统，对数据的权限管控

一个通用的数据流优化理念：合并、分片和节流

前端：

VDOM 的出现和进一步优化：VDOM（Virtual DOM）的核心理念是合并高频次的 DOM 操作，以减少渲染时间。通过生成内存中的虚拟 DOM，我们可以对内存 DOM 进行合并操作，从而减少对真实 DOM 的修改次数。React 等库就是沿着这个发展路径不断优化的。
持续高频计算阻塞渲染优化：为了提升网页的渲染流畅度并优化在持续高频计算场景下的渲染阻塞问题，我们借鉴了操作系统中的作业管理技术。具体实施方案包括将复杂的代码逻辑划分为多个较小的作业单元，实现作业的分片调度。此外，通过引入作业恢复和优先级排序机制，确保渲染任务可以得到优先执行，从而避免长时间的渲染阻塞，确保用户体验的流畅性。

这个理念在React中指的是"时间切片"（Time Slicing）和"并发模式"（Concurrent Mode）。时间切片允许React在渲染过程中根据需要将任务分割成小块并暂停和恢复，这样就可以避免长任务阻塞浏览器渲染。并发模式则是一组新的特性，它允许React在渲染时进行任务的中断、优先级判断和恢复，从而提高应用的响应性。

这些特性首次在React 16.x的alpha版本中作为实验性功能引入，而后在React 18中正式引入并发模式作为稳定功能。React 18在2021年3月发布了第一个公开的Alpha版本，并在2022年正式发布了稳定版本。因此，如果你所说的理念指的是时间切片和并发模式，那么它是在React 18中正式成为稳定特性的。所以软件发展到当前的程度，各种所谓新领域的新东西，其核心理念也是早就发明了的，只是换了种说法。

重复操作的防抖和节流，弃用部分请求

后端：

缓存层：以缓存层为例，可以将多个请求的缓存操作合并为一个，减少数据库查询的次数。同时，可以将缓存数据分片存储，提高缓存的可用性和扩展性。通过合并操作和分片，可以提高系统的性能和响应时间。
数据库读写分离：在数据库读写分离的情况下，可以将多个读请求的操作合并为一个，以减少数据库查询的次数。同时，可以将数据分片存储，提高数据库的可用性和扩展性。通过合并操作和分片，可以提高系统的性能和响应时间。
消息队列：以消息队列为例，当多个消息需要发送到同一个目的地时，可以将它们合并为一个消息，以减少网络传输次数。同时，可以将消息队列中的消息分片存储，以提高系统的可用性和扩展性。通过合并操作和分片，可以提高系统的性能和响应时间。
QPS限制等限流技术，弃用部分请求

在优化数据流性能时，我们通常会向核心层或基础设施层添加工具集或工具库，以实现对应的性能监控和数据流优化。

存储设计：

是对数据储存时的结构进行设计

当前的存储数据结构类型

行列储存

关系型数据库，如 MySQL、Oracle 等，通常采用行列存储结构来存储数据。
NoSQL 数据库，如 MongoDB、Cassandra 等，也可以采用行列存储结构来存储数据。
列式存储数据库，如 HBase、Cassandra 等，通常采用列式存储结构来存储数据。

图存储

图形数据库，如 Neo4j、GraphDB 等，通常采用图存储结构来存储数据。
知识图谱数据库，如 RDF 数据库、Ontology 数据库等，也可以采用图存储结构来存储数据。

对象存储

对象存储服务，如 Amazon S3、Google Cloud Storage 等，通常采用对象存储结构来存储数据。
文件系统，如 NTFS、EXT4 等，也可以采用对象存储结构来存储数据。

选择存储数据结构的因素

数据模型：不同的数据模型适合不同的存储数据结构。例如，关系型数据模型适合行列存储，而图形数据模型适合图存储。
数据访问方式：不同的存储数据结构支持不同的数据访问方式。例如，行列存储适合随机访问，而列式存储适合批量访问。
数据规模：不同的存储数据结构适用于不同的数据规模。例如，关系型数据库适合处理小型到中型的数据集，而分布式文件系统适合处理大型的数据集。
性能需求：不同的存储数据结构具有不同的性能特征。例如，列式存储适合处理分析型查询，而图形数据库适合处理复杂的关联查询。
成本：不同的存储数据结构具有不同的成本。例如，关系型数据库通常比 NoSQL 数据库更昂贵，而分布式文件系统通常比关系型数据库更便宜。

存储设计的原则

数据完整性：存储设计应该确保数据的完整性和一致性。
数据可用性：存储设计应该确保数据的可用性和可靠性。
数据安全性：存储设计应该确保数据的安全性和隐私性。
可扩展性：存储设计应该考虑到未来的数据增长和系统扩展。
性能优化：存储设计应该考虑到性能优化，以提高数据访问的效率。

存储设计的流程

需求分析：了解业务需求和数据特点，确定存储的数据类型和数据量。
数据模型设计：根据需求分析的结果，设计合适的数据模型。结合领域模型，设计数据表。
表设计：一般一个实体可以映射为一个数据库表。

对于泛化的不同实现方式：

泛化的数据库实现方式	优点	缺点	场景
每个类一个表	- 和领域设计对应 - 不会浪费空间 - 差异点的非空约束实现更合理 - 不易腐化	- 大部分场景需要联表查询，性能慢	对性能没有什么强需求
每个子类一个表	- 不会浪费空间 - 部分场景不需要联表，性能快 - 不易腐化 - 差异点的非空约束实现更合理	- 全局场景，可能需要两个表一起去重，查两次表而损失性能 - 和领域设计的对应还差一点	查重场景少的情况
整个泛化一个表	- 不需要联表查询，时间最快。 - 表少，简化	- 容易混淆、腐化 - 子类的差异点会浪费空间 - 和领域设计对应不上（变成一坨了）	对性能要求高

举例：

之前我们定义了实体，我们以这些实体进行数据库设计

数据库表设计：

这里对于用户的泛化，采用所有实体放到一张表，然后使用type 和 responsibilities

有了领域模型之后，领域模型可以比 ER 图表达更多的信息，因此就无需使用 ER 图了。可以说，领域模型是 ER 图的超集。

存储选型：根据数据模型和性能需求选择合适的存储技术和产品。
存储架构设计：设计存储系统的架构，包括存储节点的布局、存储网络的拓扑结构等。
性能优化：根据存储架构和业务需求进行性能优化，包括缓存设计、索引设计、数据分片等。
安全设计：设计存储系统的安全机制，包括访问控制、数据加密、备份恢复等。
测试和验证：进行存储系统的测试和验证，以确保其满足业务需求和性能要求。
部署和运维：部署存储系统，并进行运维和监控，以确保其稳定运行。

存储设计的挑战

数据一致性：存储设计需要考虑到数据的一致性，确保多个节点上的数据是一致的。
性能优化：存储设计需要考虑到性能优化，以提高数据访问的效率。
可扩展性：存储设计需要考虑到可扩展性，以适应未来数据增长和系统扩展的需求。
数据安全性：存储设计需要考虑到数据的安全性，确保数据不被泄露或篡改。
成本控制：存储设计需要考虑到成本控制，以确保存储系统的建设和运维成本在可接受的范围内。

存储设计的发展趋势

云原生存储：随着云计算的发展，云原生存储成为存储设计的重要趋势。云原生存储具有弹性扩展、高可用性、自动化管理等优点，可以更好地适应云计算环境下的存储需求。
容器存储：随着容器技术的发展，容器存储成为存储设计的新趋势。容器存储可以更好地支持容器化应用的存储需求，提高存储的灵活性和可移植性。
人工智能存储：随着人工智能技术的发展，人工智能存储成为存储设计的新趋势。人工智能存储可以更好地支持人工智能应用的存储需求，提高存储的效率和性能。
边缘存储：随着物联网和边缘计算的发展，边缘存储成为存储设计的新趋势。边缘存储可以将数据存储在靠近数据源的地方，减少数据传输的延迟和成本，提高存储的效率和性能。

部署设计：

是对系统运行的物理架构进行设计

部署设计是对系统运行的物理架构进行设计，包括硬件选择、网络拓扑、基础设施、操作系统、应用程序和数据存储等方面。部署设计的目标是确保系统在不同场景下的可靠性、可用性、可扩展性和安全性，同时满足性能需求和成本效益。

在部署设计过程中，需要考虑以下几个方面：

硬件选择：根据系统的性能需求和成本效益，选择合适的服务器、存储设备、网络设备和安全设备等。同时，还需要考虑硬件的可扩展性和冗余性，以满足未来系统的扩展需求。
网络拓扑：设计合理的网络拓扑结构，确保系统的各个组件之间能够进行高效的数据传输和通信。同时，还需要考虑网络的可靠性和安全性，以防止数据泄露和网络攻击。
基础设施：搭建可靠的基础设施，包括电力供应、冷却系统、消防系统等，以确保系统的稳定运行。同时，还需要考虑基础设施的可维护性和可扩展性，以方便未来的升级和维护。
操作系统：选择适合系统的操作系统，确保系统的各个组件能够在操作系统上稳定运行。同时，还需要考虑操作系统的安全性和可维护性，以防止操作系统漏洞和故障对系统造成影响。
应用程序：设计合理的应用程序架构，确保系统的各个组件能够高效协同工作。同时，还需要考虑应用程序的可扩展性和可维护性，以方便未来的升级和维护。
数据存储：选择合适的数据存储方案，确保系统能够高效存储和管理数据。同时，还需要考虑数据存储的安全性和可扩展性，以满足未来系统的数据增长需求。

综上所述，部署设计是系统运行的重要基础，需要综合考虑各个方面的因素，以确保系统的可靠性、可用性、可扩展性和安全性。在部署设计过程中，需要不断优化和调整设计方案，以满足系统的实际需求和运行情况。

总结

架构设计的基础要素包括以下几个方面：

产品架构。在理解别人的架构时，我们首先需要了解其产品架构，即系统的整体结构和各个组成部分之间的关系。
功能模块架构。接下来，我们需要关注功能模块架构，以确保其满足产品的功能需求。这包括检查各个模块之间的交互方式、模块的划分是否合理、是否存在功能重复或缺失等问题。
代码模块分层。然后，我们需要查看代码模块的分层是否简洁合理。一个良好的分层结构可以提高代码的可读性、可维护性和可扩展性。我们需要关注模块之间的依赖关系、是否存在不必要的耦合以及层次是否清晰等问题。
数据流模型。数据流模型是指系统中数据的流动方式和处理逻辑。我们需要检查数据流模型是否存在各种性能、监控上的问题，例如数据瓶颈、数据一致性问题、数据处理延迟等。
存储设计。最后，我们需要关注存储设计是否能够满足系统的各方面要求，包括存储容量、性能、可靠性等。这包括选择合适的存储技术、设计合理的数据存储结构以及确保数据的安全性和一致性等问题。

综上所述，通过对产品架构、功能模块架构、代码模块分层、数据流模型和存储设计等方面的综合分析，我们可以全方位地设计或理解一个架构。

大概梳理一下架构经验

前言