用途
本技能是事件建模流程的第 6 步，用于应用康威定律（Conway's Law），借助泳道（swimlanes）把事件组织成自治的系统部分，使不同团队能够独立拥有各自的系统。其核心思想是：系统架构应映射团队结构——独立的团队对应独立的系统，每个系统拥有自己的事件，通过事件进行通信，从而实现独立开发。
主要能力
- 判断是否需要访谈：若用户已提供清晰的团队结构（谁拥有什么）、期望的自治程度以及已识别的外部集成，则跳过访谈，直接进入泳道划分；否则先进行访谈。
- 访谈围绕三类关键问题：
- 团队结构与所有权（决定创建多少泳道/系统）：组织是单一团队拥有全部、按领域划分团队，还是按职能划分团队。
- 边界自治程度（决定耦合与团队间通信模式）：非常高（最少跨团队沟通）、中等（通过事件协调）、低（可接受频繁耦合）。
- 外部系统集成（决定集成是成为独立泳道还是嵌入现有泳道）：支付处理器、物流提供商、多个外部系统，或无外部集成。
- 将访谈结论追加到项目的事件建模文件中，路径为
.trogonai/interviews/[project-name]/EVENTMODELING.md，并更新访谈记录表。 - 按所有权组织全部事件、输入与输出，具体包括：
- 识别系统边界（确定什么构成独立系统/限界上下文，例如订单管理、支付处理、库存、履约等系统各自拥有哪些实体、事件与状态机）。
- 创建泳道图（以事件流时间线可视化系统边界，每个团队拥有自己的泳道事件，通过跨泳道事件协调）。
- 映射团队职责（每个团队处理的命令、产生的事件、维护的读模型、调用的系统）。
- 识别系统间通信（系统之间如何通过事件与处理器相互触发）。
- 定义系统接口（每个系统接受的命令、产生的事件、提供的读模型）。
- 区分处理器与系统（自动化逻辑所在位置，例如 PaymentProcessor、InventoryProcessor、FulfillmentProcessor、NotificationProcessor 的触发事件、逻辑、产生的命令与所属系统）。
使用方式
技能以访谈与工作流两种方式推进。访谈为可选阶段，按条件进入：若用户已提供清晰团队结构、期望自治程度并识别了外部集成，则跳过访谈直接进入泳道划分；否则依次进行组织评估（问题 1-2）与集成映射（问题 3）。工作流则按上述六个步骤组织事件与系统，最终以指定输出格式呈现，包括：系统组织文档（每个系统的团队、职责、命令、产生事件、消费事件、读模型、依赖、范围）、跨系统边界的事件流、团队职责矩阵、系统间通信、依赖关系（外部系统表）、独立开发说明。
适用场景
适用于事件建模后期需要将事件与系统按团队所有权进行划分的场景，尤其是组织内存在多个团队、需要明确自治边界、需要设计跨团队事件通信、或需要与外部系统集成的情况。也适用于团队结构或组织对齐尚不清晰、需要先通过访谈厘清边界的场景。
限制
技能本身未提供具体技术栈、部署方式或性能指标等实现细节。访谈为可选，若跳过则依赖用户已提供的信息。输出中的示例（如订单、支付、库存、履约等系统）为演示性内容，实际系统边界需依据具体项目与团队结构确定。技能未说明收费、价格或平台限制等信息，资料中暂未提供。