先确定要查哪一类设计
“模组化”也常写作“模块化”。查找前应明确对象：是交易执行、数据发布等链架构职责的分工，还是智能合约的代理、实现与升级机制。两类文档解决的问题不同，单独搜索“区块链模块化”容易混入大量概念介绍。
如果关注扩容方案怎样协作，可从 scaling、rollups、data availability 等词入手；如果关注合约功能如何复用或升级，则可搜索 proxy、implementation、upgradeability，并加上技术名称或版本。
链架构方向：从扩容概览定位专题
以太坊开发者文档的 Scaling 页面可作为扩容方向的入口，地址为 https://ethereum.org/developers/docs/scaling/。该页介绍链上与链下扩容，并说明 Rollup 将执行移到第一层之外，再向第一层发布数据；不同方案的数据位置和安全机制存在差异。
这个入口适合建立概念关系。继续查设计时，应根据问题寻找对应专题：执行结果怎样验证、数据在哪里发布、何时完成结算。阅读时把这些问题分别记录，避免仅凭“链下执行”就认定不同方案具有相同安全属性。
合约方向：从代理接口追到机制说明
OpenZeppelin Contracts 的代理 API 文档入口为 https://docs.openzeppelin.com/contracts/5.x/api/proxy。其内容区分 Transparent、UUPS、Beacon 和最小代理等机制：UUPS 的升级逻辑位于实现合约，Beacon 可让多个代理跟随同一实现地址；最小代理主要用于固定实现的低成本克隆。
这个入口适用于合约代理与升级设计查询。检索时可组合具体模式与 storage、initialization、access control 等词，并通过文档中的标准编号定位相关规范，重点理解状态存储、初始化和升级权限的关系。
怎样判断找到的是设计依据
概览帮助理解目标，规范描述规则，API 说明接口，实现代码体现具体行为。查询时可沿这些层次逐步核对，而不要把一个接口列表当作完整架构说明。设计文档应能回答模块负责什么、依赖什么、如何交互，以及异常发生后由谁处理。
版本也要一致。记录文档版本、适用组件和对应实现；若出现不同描述，应先检查是否来自不同版本或不同代理模式，再判断是否存在矛盾。
常见问题与适用范围
找不到名为“设计文档”的页面怎么办？可继续查找 architecture、specification、design、proposal 等栏目名称，设计依据可能分散在规范与机制说明中。
代理文档能否说明整条区块链的模组化架构？它主要解释合约层的职责拆分。扩容概览则帮助定位链架构问题。两类入口需要按研究对象选用，不能相互替代，也不能据此推断某个项目已经采用特定设计。