Pico‑CRM 是一个家政领域的 SaaS 程序，Rust 全栈。它的业务不复杂：家政公司接客户

独立开发最怕的痛点：功能写完了却没有人使用。

在开工前。我画了一条线——主要链路深度实现，非主要链路只提供最简可跑版本。话说回来，下面把这条线背后的判断逻辑写清楚：不是拍脑袋。而是基于业务特征，

一、主要链路：四条，全部事件溯源

家政 CRM 最主要的业务流只有四个节点：

客户来电 → 建需求 → 转订单 → 排班派单 → 完工

对应到代码里是三个聚合根，全部上了事件溯源：

为什么这三样要上事件溯源？

它们是纠纷高发区。从比如来看，

• 哪个客服把“待确认”点成了“已派单”？
• 哪个阿姨的排班被改过？订单金额什么时候从 X 元 改成 Y 元？

  这些问题在事件流里精确到秒就能回答，无需额外维护 changelog。

  事件溯源不是银弹，但恰好击中了家政领域最痛的点——服务纠纷需要完整时间线。

  每个聚合都有对应的投影监听器。后台 Tokio 任务持续消费事件写入读模型，前端查询读模型，写操作走事件存储。

  二、非主要链路：直接写库，没有状态机

  售后服务的观点是，status 用 String 而非枚举

  // backend/src/domain/crm/after_sales/model.rs
  pub struct AfterSalesCase {
  pub uuid: String,pub order_uuid: String,pub case_type: String,pub description: String。pub status: String,// ← 不是枚举，是 String
  pub refund_amount_cents: Option,// ...
  }
  pub fn validate_after_sales_status -> Result<, String> {
  match value {
  "open" | "processing" | "resolved" | "closed" => Ok),_ => Err),}
  }
  

  MVP 阶段我故意不给它上状态机。 售后流程真实形态尚未确定——是“退款→重做→回访”三步还是“一步赔钱”？在不知道之前，用字符串保持灵活；等跑通后再收敛为枚举，

  从售后返工调度来看，仅有创建接口的极简实现

  // backend/src/domain/crm/after_sales_rework/model.rs
  pub struct AfterSalesRework {
  pub uuid: String,pub case_uuid: String,pub assigned_user_uuid: String,pub assigned_user_name: Option,pub scheduled_start_at: DateTime,pub scheduled_end_at: DateTime,pub note: Option。pub status: String,// ← 没有状态枚举
  pub created_at: DateTime,}
  pub struct CreateAfterSalesRework {
  pub case_uuid: String,pub assigned_user_uuid: String,pub scheduled_start_at: DateTime,pub scheduled_end_at: DateTime,pub note: Option,}
  pub trait AfterSalesReworkRepository : Send + Sync {
  fn create_rework
  -> impl std::future::Future
  
  + Send;说起来，}
  

  整个文件只有约 64 行。只实现了创建方法，没有更新、取消，也没有状态枚举。对比主要链路里的完整状态机与事件溯源，这就是“最简可跑版本”。如果真的需要返工调度，只要先能录进去再说；等实际案例出现，再补齐更新、完成等操作。

  从客户管理来看，所有非必填字段均为 Option 

  pub struct Contact {
  pub uuid : String,pub name : String,pub phone : String,// 以下均可空，因为不知道哪些字段会被实际使用
  pub address : Option,pub community : Option。pub building : Option,pub house_area_sqm : Option,pub service_need : Option,pub tags : Vec,}
  

  User Pain Point： 不同家政公司记录信息的习惯千差万别。如果把所有字段都设为必填，会导致大量空值或强制填写无意义的数据。先开放所有字段，用一段时间观察填充率，再把高频字段收敛为必填。话说回来，

  说到服务目录，纯 CRUD，没有状态字段 

  // ServiceCatalog.rs
  pub struct ServiceCatalog {
  pub uuid : String。pub name : String,pub price_cents : i64,}
  

  这是一个定价表，“深度保洁 ¥ 120/次”。不涉及业务流转，不需要审计，自然不必引入复杂架构。

  // backend/src/domain/crm/service_request/model.rs
  pub enum ServiceRequestSource {
  SalesManual,// ← 就这一个值
  }
  

  因为第一个商户只用

  "今天真实有人用的链路」→ 深度实现。 未验证需求」→ 最简可跑版本（直接写库 + 字符串状态 + 最少方法)。"

  1. 有纠纷追溯需求 ⇒ 事件溯源。 订单、排班、需求变更必须能回溯到秒级；客户信息和定价则不需要审计。
  2. 有明确状态流转 ⇒ Rust 枚举 + 状态机。不过， OrderStatus/Schedu leStatus` 等必须穷尽匹配；售后流程尚未定型，用字符串先跑。
  3. "如果会用" 的功能 ⇒ 不写或极简实现。 SERVICE_REQUEST_SOURCE only one variant,AfterSalesRework only create method. 真正需要时编译器会提醒你补全分支。

  程序仍未上线，我判断“高频”和“低频”并非靠数据。而是靠"业务特征".

  • Main Path ： 客户来电 → 客服录入需求 → 确认生成订单 → 排班派阿姨 → 完工。每一步都不可跳过是程序的"心跳".
  • If‑Path ：
    • If 客户投诉 ⇒ 售后流程；
    • If 投诉需重做 ⇒ 返工调度；
    • If 商户想开小程序 ⇒ 在线预约。

  对比建筑施工的观点是。主干道每天都有车流，需要沥青、标线与灯光；消防通道十年可能才用一次只要压实碎石即可。再看代码同理，

  • 主要链路铺沥青：事件溯源保证审计能力。状态机保证流转正确，投影监听保证查询性能；
  • 至于链路压实碎石。直接写库能跑就行，等真的有车流再升级。话说回来，

  风险意识一样关键。话说回来，如果售后模块第一周就爆炸，现在仅 ~64 行实现肯定撑不住。但从字符串升级到枚举，从直写库升级到事件溝源，仅需少量代码改动。而且都是在真实需求驱动下进行，不会成为沉没成本。

  相反，如果一开始就把售后做成完整事件溯源+状态机。却在三个月内根本没人投诉，那删也不是、留也不是每次改动主要链路都要牵扯它。**未验证功能越早实现，其沉没成本越大**。

  独立开发 SaaS 产品最大的成本不是写代码，而是"维护没人用的代码".

  • #1 先画一条线：哪些是业务必然发生？哪些是「如果」才发生，
  • #2 必然发生深度实现：事件溯源、状态机、完整测试——该上就上。怎么说呢，
  • #3 「如果」给最简版：能跑就行。不提前设计——真需要时再加，改起来比删掉更轻松。