很多项目把数据库迁移放在部署脚本里，结果最容易漏的也是这一步。本文结合 Pico-CRM 的真实实现，聊聊我为什么把 SeaORM 的 20 个 migration 放到 `server/src/main.rs` 启动阶段同步执行，以及这种做法在单二进制部署、多租户共享表、默认数据初始化里的实际价值和边界。

Pico-CRM 的订单不是简单存一个 `status` 字符串，而是在领域层定义了 6 个状态、合法流转、取消终态、排班联动和事件溯源决策。本文结合真实代码，聊聊我为什么没有把状态判断散落在接口里，以及状态机在业务系统里到底该管到什么程度。

给家政 SaaS 做权限模型，没有用 RBAC 库也没有上 CASL，四个角色（admin/merchant/operator/user）、两条中间件（页面重定向 + API 拦截）、Cookie HttpOnly + HS256 签名，全部在 Axum 和 Leptos 里手写落地。本文从角色定义、JWT 签发、中间件双通道设计、前端菜单驱动四个层面拆解实现细节，分享"不做过度抽象"的权限设计思

后台管理系统中表格无处不在，但手写 `<table>` 意味着排序、加载态、空状态在每个页面重复造轮子。本文介绍如何在 Rust + Leptos 全栈项目中设计一个不到 200 行的泛型表格组件，通过 Column 插槽、Provider 注入和 Identifiable trait 三个模式，让列表页开发从"复制粘贴"变成"声明式配置"。目前已在 Pico-CRM 的 6 个业务页面中稳定运行

给 Pico-CRM 上事件溯源的时候，面临一个选择题——事件存储和读模型，放同一个库还是分开？起初觉得放一个库省事，一个连接池、一套 migration、一个 `docker run` 搞定。但实际跑起来后发现，事件存储的写入模式（append-only 高频顺序写）和读模型的查询模式（随机读 + 索引 + JOIN）完全是两种性格。最终拆成了两个 PostgreSQL 实例，事件存储专用库（`

CQRS 多实例部署时，投影监听器不能每台都跑——同一个事件被多台机器各自投一次，读模型直接乱套。常见的选主方案要么引入 ZK/etcd，要么自己搓一套 Redis 分布式锁+心跳续约。但如果你已经有 PostgreSQL，`pg_try_advisory_lock` 一个函数调用就能搞定，锁跟着连接走、连接跟着进程走，进程挂了锁自动释放，连清理逻辑都不用写。本文拆解 Pico-CRM 中基于 P

DDD 里跨聚合操作是个经典难题——Saga 太重，塞 Handler 太丑，Domain Service 又拿不到数据库连接。本文复盘 Pico-CRM 中 OrderAppService 的设计思路：一个 struct 注入五个泛型，顺序执行替代分布式事务，纯函数映射保证最终一致性，没有 Saga、没有 DI 容器、没有额外框架。

一个main.rs里跑完 migration + CQRS + 投影监听 + HTTP 服务，不是偷懒，是刻意设计的部署简化。Migration 启动时同步执行——部署不需要额外脚本，SeaORM 内部跳过已执行的事件存储 schema 由 disintegrate 自动管理——枚举里#[id]字段直接映射到 domain_id 列PG Advisory Lock 做投影 Leader 选举——零

DDD 分层架构在 Java 里有 Spring 做依赖注入，在 Rust 里怎么办？本文记录了我在 Pico-CRM 项目中用 Rust trait + 泛型 + 构造器注入实现 domain/application/infrastructure 三层架构的完整过程。没有 DI 容器、没有框架黑魔法，靠 Rust 类型系统本身就实现了严格单向依赖。包含各层真实代码、mock 测试方案、trait