一、disintegrate：让业务逻辑从框架中解耦

disintegrate 并不是一个“全能框架”，而是一套 trait 的组合，帮助你把业务逻辑写成纯函数：

• Decision定义业务操作的意图，主要方法是 process -> Result。Error>
• StateMutate描述事件如何折叠回状态，主要方法是 mutate
• StateQuery事件流查询。

这三者共同构成闭环：加载事件 → 折叠成当前状态 → 根据状态产生新事件 → 新事件追加到流。说起来，框架负责加载、折叠与持久化。你只需实现事件结构、折叠逻辑还有每个操作的意图。说起来，

二、痛点一：Service 层越写越“心虚”

在传统 Service 层里业务往往被拆散到校验、状态切换、SQL 拼接、日志等多处。一个“取消订单”功能可能涉及数百行代码，还夹杂两处if判断——过了两周就不敢改。

这导致的观点是，

• 代码难以定位；
• 错误易被隐藏；
• 变更成本高，风险大。

你是否也有差不多困扰？

三、Decision：把业务规则写成纯函数

// backend/src/domain/crm/order/es/decisions.rs
pub struct CancelOrderDecision {
merchant_id: String。order_uuid: String,reason: String,updated_at: DateTime,operator_uuid: Option,}
impl Decision for CancelOrderDecision {
type Event = OrderEventEnvelope;type StateQuery = OrderState;type Error = String;说起来，fn state_query -> Self::StateQuery {
OrderState::new
}
fn process -> Result。Self::Error>{
let mut order = state.to_domain?，order.cancel)?，Ok
}
}

This single process` method reads current state,runs domain logic and emits events—no DB queries,no side‑effects.

说到纯函数的好处。

• Dart-typed compile‑time safety.
• No hidden I/O or async baggage.
• Easier reasoning and refactoring.

四、StateMutate：事件→状态的透明映射

// backend/src/domain/crm/order/es/state.rs
impl StateMutate for OrderState {
fn mutate {
match event {
OrderEvent::OrderCreated { merchant_id,order_uuid,status,.. } => {
self.exists = true;self.merchant_id = merchant_id;self.order_uuid = order_uuid;self.status = Some;// 初始化其他字段
}
OrderEvent::OrderStatusChanged { status。completed_at,updated_at,.. } => {
self.status = Some;self.completed_at = completed_at;self.updated_at = Some;}
OrderEvent::OrderCancelled { cancellation_reason。updated_at,.. } => {
self.status = Some.to_string);self.cancellation_reason = Some;self.completed_at = None;self.updated_at = Some;其实，}
// ...
}
}
}

No I/O or async – just field assignments.

to_domain: 把扁平状态变回完整领域对象

// backend/src/domain/crm/order/es/state.rs
pub fn to_domain -> Result{
if!
self.exists{
return Err);}
Ok(Order{
说到uuid，self.order_uuid.clone。status: OrderStatus::parse.unwrap_or)?amount_cents:self.amount_cents,// ...
})
}

The returned Order is a normal domain object unaware of event sourcing.

五、主要体验：给定历史事件直接跑单元测试。无需数据库或 Docker

1. {Given}: 用历史事件构造状态。
2. {When}: 调用 Decision 的 process.
3. {Then}: 验证返回的事件或错误信息。

// backend/src/domain/crm/order/es/decisions.rs
#
fn it_rejects_invalid_status_transition{
TestHarness::given)])
.when)
.n_err);}

The built‑in TeshHarness — a chainable API that folds everything into a few lines of code.

说到速度对比。

• *传统方式*的观点是，docker-compose up → 启动容器 → 编译 + 测试 ≈ 秒级。
• *disintegrate*: 单元测试 ≈ 毫秒级。
*体验改善*;*开发效率提高*;*持续集成成本降低*;*更少运行时错误*.

六、Repository 层只做决策包装。完全脱离业务逻辑编写细节

// backend/src/infrastructure/repositories/crm/orderrepositoryimpl.rs
async fn cancelorder(
&self,uuid:String,reason:String,…)>Result{
let decisionmaker =
disintegratepostgres::decisionmaker;

decisionmaker.make( CancelOrderDecision::new,operatoruuid) ).await?，

再看Self:，loadorderfromevents } `` decisionmaker.make` encapsulates four responsibilities:

1️⃣ Load history via state_query. 2️⃣ Fold it into current state with mutate. 3️⃣ Execute business logic through process. 4️⃣ Persist new events atomically.

The repository never touches business rules—just orchestrates pure functions.

---

聚合	Decision 数	典型操作
Order	6	Create / UpdateDetails / StatusChanged / Cancel / Assignment / SettlementSchedule
Schedule	4	Create / UpdateAssignment / StatusChanged / DeleteServiceRequest
ServiceRequest	3	Create / UpdateDetails / StatusChanged

Total Decisions : **13** + tests : **…** . Each test is only three lines of Given/When/Then.

四步流程。零运行时风险

1️⃣ 定义新事件 2️⃣ 实现对应 Decision trait 3️⃣ 在 StateMutate 中补全 mutate 分支 4️⃣ 写 Given/When/Then 测试 所有步骤均为纯函数，编译期即检查完成。老实说，不存在“忘记改某处导致运行时崩溃”的隐患。

---

八、——用纯函数摆脱 Service 层困境。并提高整体开发体验 ⚡️💡🎯

• process: 给定相同 state，总会产生相同 events。无隐藏库访问，也不做 HTTP 或修改全局变量。
• mutate: 给定相同 events 序列，总会得到相同 state。可任意重放，无副作用，• TestHarness: 将 Given/When/Then 封装为链式调用。用几百行代码跑完所有用例，只需毫秒级即可获得结果。

• 将副作用推到最外层，主要原因保持可推理且易于验证。

• 体验从“连着数据库一起测”转为“一键跑测试即刻反馈”。

---

**痛点再盘点**

场景	原始痛点	disintegrate 解法
业务耦合	Service 层混杂 SQL 与领域逻辑	决策与折叠分离，仅由纯函数决定行为
改动成本	修改一行就得跑容器+DB +复测	单元测试仅依赖内存数据。可快速迭代
测试可靠性	模拟 DB 或 mock 不稳定	所有方法可在本地 deterministically 执行
团队协作	难以定位责任边界	明确职责区块

如果你现在正面临上述问题，请考虑把业务逻辑抽象为纯函数。试试看它能否帮你把繁琐的 Service 层拆解开来？

---

项目已开源 GitHub 上，搜索 Pico‑CRM 可查看完整代码与示例。

---

---