第2章 架构
架构不是目录命名,而是把变化频率、依赖方向、运行约束和团队边界转成可检查决策。Unity 前端架构还要处理 MonoBehaviour 生命周期、场景引用与资源异步性,不能机械照搬服务器分层。
从连载位置与先预测开始
本页对应陆泽西(Jesse Lu)《Unity3D 高级编程之进阶主程》的第2章。该作品是在线技术连载,不是有 ISBN 的正式出版书;原作者旧站已不可作为稳定入口,因此以保存下来的完整文章索引核对章节,并保留原始标题与编号。
架构不是目录命名,而是把变化频率、依赖方向、运行约束和团队边界转成可检查决策。Unity 前端架构还要处理 MonoBehaviour 生命周期、场景引用与资源异步性,不能机械照搬服务器分层。
原连载文章覆盖矩阵
| # | 原文章主题或本页检查点 | 可观察解释 |
|---|---|---|
| 1 | 架构的意义 | 用可演进边界降低跨模块修改和故障扩散。 |
| 2 | 软件系统架构思维方式 | 从质量属性、约束、风险和权衡推导结构。 |
| 3 | 架构的误区 | 拒绝为模式而模式、全局单例和一次性大重构。 |
| 4 | 前端架构 | 处理表现、状态、资源、输入与平台生命周期。 |
| 5 | Unity3D 项目架构 | 把引擎适配层与领域规则、数据和工具链分开。 |
架构的意义、软件系统架构思维方式、架构的误区、前端架构、Unity3D 项目架构 不是随意补充的主程知识清单,而是沿“列出质量属性 → 画出现有依赖 → 识别变化轴 → 定义模块契约 → 迁移一条用例 → 验证故障边界”建立因果关系。每个条目都要能定位到实验输入、首个状态变化和最终门禁。
核心模型与技术边界
架构不是目录命名,而是把变化频率、依赖方向、运行约束和团队边界转成可检查决策。Unity 前端架构还要处理 MonoBehaviour 生命周期、场景引用与资源异步性,不能机械照搬服务器分层。
连载写作年代与今天的 Unity、.NET 后端和渲染管线存在差异。复现时保留作者要解释的机制,同时记录旧 API、当前替代路径、运行时版本和验证结果。没有版本映射的“更新版结论”不能覆盖原文章,也不能把今天的默认行为倒推成当年的事实。
必须在本页留下输入、内部状态和输出证据,不能只作为术语出现。
必须在本页留下输入、内部状态和输出证据,不能只作为术语出现。
必须在本页留下输入、内部状态和输出证据,不能只作为术语出现。
必须在本页留下输入、内部状态和输出证据,不能只作为术语出现。
必须在本页留下输入、内部状态和输出证据,不能只作为术语出现。
六阶段主程证据链
可复现实验
选择登录到大厅的一条真实用例,画出 UI、业务、网络、配置和资源依赖。先预测需求变化会波及哪些模块,再把传输层替换为模拟实现并比较修改范围。
最小实现只暴露本章关键状态,不把因果藏进通用框架。
public interface ILoginGateway
{
System.Threading.Tasks.Task<LoginResult> LoginAsync(string token);
}
public sealed class LoginUseCase
{
private readonly ILoginGateway gateway;
public LoginUseCase(ILoginGateway gateway) => this.gateway = gateway;
}统一证据契约把结构、版本和故障计划放在同一结果中。
type LeadProgramEvidence = {
chapter: "u3ap-02-architecture";
runtimeVersion: string;
sample: "baseline" | "boundary" | "failure";
stages: readonly string[];
firstDeviation: string | null;
decision: "pass" | "rejected";
};
function canRelease(run: LeadProgramEvidence): boolean {
return run.stages.length === 6 &&
(run.sample !== "failure" || run.decision === "rejected");
}证据日志至少保留下列字段,并与捕获文件使用同一运行编号。
stage,name,sample,input,observation,result
1,列出质量属性,baseline,planned,observed,pass
2,画出现有依赖,baseline,planned,observed,pass
3,识别变化轴,baseline,planned,observed,pass
4,定义模块契约,baseline,planned,observed,pass
5,迁移一条用例,baseline,planned,observed,pass
6,验证故障边界,baseline,planned,observed,pass两个必须主动制造的失败
验收矩阵
| 维度 | 正常样本 | 边界样本 | 失败样本 | 通过条件 |
|---|---|---|---|---|
| 连载 | 原主题逐项定位 | 相邻文章交叉 | 故意漏一项 | 无主题空洞 |
| 结构 | 依赖和状态可见 | 极限规模与阈值 | 注入错误边界 | 首偏离可定位 |
| 运行 | 固定输入可回放 | 长尾与平台差异 | 故障计划 | 结果可复现 |
| 交接 | 他人按证据复验 | 干净环境 | 删除隐含依赖 | 不变量成立 |
练习
小结
- 已覆盖 架构的意义、软件系统架构思维方式、架构的误区、前端架构、Unity3D 项目架构,没有用自拟的热更新或 CI/CD 目录替代原连载。
- 已沿“列出质量属性 → 画出现有依赖 → 识别变化轴 → 定义模块契约 → 迁移一条用例 → 验证故障边界”保存正常、边界、失败与修复证据。
- 已记录原写作年代与当前 Unity 的版本映射。
- 已以“一条业务用例可以在不启动完整 Unity 场景和真实网络的条件下验证,依赖只沿声明方向流动。”作为交接门。