Skip to article frontmatterSkip to article content
Site not loading correctly?

This may be due to an incorrect BASE_URL configuration. See the MyST Documentation for reference.

架构设计文档

这套规则的核心原则是:领域模型(数据)与 UI 组件(视图)分离。

  1. 领域模型命名(数据层 / 业务逻辑)

这一层代表了业务的本质,名字要严谨、准确,符合用户故事地图的方法论。

  1. UI 组件命名(展示层 / Flutter Widget)

这一层代表了屏幕上的像素和交互,名字要直观、体现形态。

需求屏采用「二维矩阵 + 跨列合并」布局(详见 需求屏设计):

  1. 命名映射对照表

为了让你更直观地理解,我做了一个映射表: 层级 业务概念 (What) 领域模型类名 UI 组件类名 (How) 备注 第一层 用户活动 (主干) UserActivity ActivityLayerRow 橙色层,跨列合并。 第二层 用户任务 (骨架) UserTask TaskLayerRow 紫色层,每列一个任务。 第三层 用户故事 (细节) UserStory StoryCard 逻辑上叫故事,视觉上叫卡片。 发布行 发布版本 (MVP/未来) UserStory.phase ReleaseRow 按版本分组的可折叠行。 容器 故事地图 StoryMap StoryMapCanvas 逻辑上叫地图,视觉上叫画布。

  1. 数据流向与组合逻辑

在代码中,它们的组合关系是这样的:

  1. 数据层:

    • StoryMap 包含多个 UserActivity。

    • 每个 UserActivity 包含多个 UserTask。

    • 每个 UserTask 包含多个 UserStory。

  2. 视图层:

    • StoryMapCanvas 接收 StoryMap 数据,经 projectToColumns() 投影为 ColumnDef[]

    • ActivityLayerRow 遍历列定义,为连续同活动的列渲染跨列合并的活动标题。

    • TaskLayerRow 遍历列定义,为每个任务列渲染任务标题。

    • ReleaseRow 遍历列定义,按 Release 版本取出各列故事,为每个 UserStory 创建一个 StoryCard。

  3. 为什么这样命名最好?

  4. 职责清晰:

    • 当你看到 UserActivity 时,你知道它是数据,里面可能有复杂的业务逻辑。

    • 当你看到 ActivityLayerRow 时,你知道它是视图,只负责怎么把数据画得好看。

  5. 避免混淆:

    • 不会把“业务上的活动”和“界面上的行/卡片”混为一谈。

  6. 易于维护:

    • 如果未来 UI 改版,比如把 ActivityLayerRow 改成别的行组件,你只需要改组件名,不需要动业务逻辑里的 UserActivity。

  7. 符合直觉:

    • 层(Layer)与行(Row)直接对应渲染结构:活动层跨列、任务层每列一个、Release 行按版本分组,视觉层级与业务层级一致。