问题与使用场景
先按六组职责定位关注点,再选择具体项目或包。
在选择包之前,使用这张矩阵定位某个关注点归属的框架构建块。
这张图适合用于方案评审、故障定位、代码走查与新人导览。它刻意省略与当前问题无关的类和项目,因此应与源码入口和相关专题文档一起使用。
本页范围只覆盖图中命名的职责和关系;未出现的能力需要回到对应模块文档继续确认。
读图路径
- 第 1 步:把行理解为职责族,而不是部署单元。
- 第 2 步:按列从策略与契约读向适配器与生成器。
- 第 3 步:通过治理单元格理解架构规则如何被执行。
读图时不要跳过箭头方向、编号和分组标题;它们分别表达依赖或时间方向、执行次序与职责边界。如果图与源码不一致,以当前源码和已接受的架构决策为准,并立即更新生成目录。
图例与表达约定
| 视觉元素 | 含义 | 不能据此推断 |
|---|---|---|
| 珊瑚色焦点 | 当前图要强调的决策点或主路径 | 该元素一定更重要或拥有更多权限 |
| 蓝色边界 | 外部系统、协议边缘或显式边界 | 一定是独立部署服务 |
| 灰色连接 | 依赖、调用、迁移或数据流,具体语义由箭头标签决定 | 一定同步、同事务或严格一次 |
| 分组框 | 职责、层或生命周期阶段 | 组织团队或物理机器边界 |
本图类型为 能力矩阵。先依据该类型理解布局,再用下文的源码事实校正直觉。
关键关系与设计含义
关系 1
源码事实:Domain 与 Application 项目定义策略和端口;Infrastructure 项目实现技术适配器。
架构含义:分离策略归属与适配器实现,可保持技术项目可替换,并让领域决策易于发现。
核对动作:哪个项目拥有契约,哪个项目负责实现?
关系 2
源码事实:源生成器覆盖 DI、端点、模块化、持久化元数据与查询形状。
架构含义:生成器把重复接线与元数据变成编译期产物,同时让业务行为保留在普通代码中。
核对动作:编译期生成能否替代运行时发现?
关系 3
源码事实:架构测试与治理生成器共同约束依赖边界。
架构含义:自动化治理把架构约定转化为失败证据,在依赖违规进入生产前阻止它。
核对动作:哪项测试或生成器会阻止边界退化?
设计评审问题
在评审或实现相关变更时,逐项回答下面的问题。无法从代码、测试或 ADR 得到答案时,不应仅凭图示作出结论。
- 哪个项目拥有契约,哪个项目负责实现?
- 编译期生成能否替代运行时发现?
- 哪项测试或生成器会阻止边界退化?
如何使用答案
- 先确定能力或规则的唯一归属方。
- 再确认依赖、调用或事件方向没有反转所有权。
- 最后用自动化测试或可重复命令固定结论。
边界与易错点
边界 1
矩阵按职责分组,并不直接表达 NuGet 包依赖方向。
- 不要推断:图中出现连接,不等于所有实现都同步调用、共享事务或共享数据所有权。
- 评审要求:编译期生成能否替代运行时发现?
边界 2
先按职责归属与策略定位关注点,再选择技术项目。
- 不要推断:图中出现连接,不等于所有实现都同步调用、共享事务或共享数据所有权。
- 评审要求:哪项测试或生成器会阻止边界退化?
源码核对与再生成
本图的首要核对入口是 src/Framework project inventory。先检查该入口及其直接引用,再重新生成图表资产和说明页。
# 重新生成中英文 SVG、独立 HTML 与说明页npm run diagrams
# 检查双语配对、引用、安全属性、可访问性与画布边界npm run verify:diagrams# 确认生成结果只包含预期图表与页面变化git diff -- scripts/diagrams diagram-sources public/diagrams src/content/docs
# 验证站内链接、MDX 结构与专业深度门禁npm run verify:docsnpm run audit:docs-depth变更完成清单
- 图中的职责、顺序、状态或关系与当前源码一致。
- 新增元素确实有助于回答本页问题,没有把项目清单全部塞进图中。
- 箭头有明确方向与关系语义,没有暗示不存在的同步或事务保证。
- 中英文标题、标签、事实与边界保持语义对等。
- 窄屏、全屏和缩放模式下均可读,没有文字重叠或越界。
- 相关架构测试、集成测试或验证命令已经执行。
- 若改变了长期约束,已经同步 ADR 或架构说明。