Title

副作用驱动设计体系（Effect-Driven Design, EDD）

一、设计哲学

副作用驱动设计（Effect-Driven Design, EDD）是一种以“副作用识别与组织”为核心的系统架构方法。它不以MVC、DDD等传统技术结构为起点，而以副作用的边界、风险和组织方式为第一性原则，构建适应变化、具备可观测性和可测试性的现代系统。

核心口号：副作用不可怕，不可控的副作用才可怕。

二、核心构成模块

Title

EDD 依赖注入策略指南：基于实践的简化方法

一、核心认知

理论与现实的差距

在 EDD 实践中，我们发现了一个关键矛盾：

• App 层希望：细粒度的依赖注入，清晰的职责分离
• Infra 层现实：同一实体的多个 trait 最终由同一个 Service 实现

// App 层的理想
pub async fn register_user(
    input: RegisterInput,
    repo: &impl UserRepository,
    validator: &impl UserValidator,
    cache: &impl UserCache,
) -> Result<Outcome<User>, AppError>

// 实际调用时
register_user(
    input,
    &*app.user_service,  // 都是
    &*app.user_service,  // 同一个
    &*app.user_service,  // Service！
).await

// 本质上等同于
register_user<S: UserRepository + UserValidator + UserCache>(
    input,
    &*app.user_service,
).await

Title

EDD 副作用驱动设计 开发过程详解以及手记

分层设计

Title

EDD 术语表

核心概念术语

副作用驱动设计 (Effect-Driven Design, EDD)

• 以"副作用识别与组织"为核心的系统架构方法

副作用 (Side Effect)

• 改变系统状态的行为，如数据库写入、API调用、发送消息等

纯化层 (Pure Layer)

• core、domain、app三层的统称，尽可能减少副作用的产生

Title

EDD 测试指南：副作用驱动架构下的多层次测试策略

一、测试的结构定位

在 Effect-Driven Design (EDD) 架构中，系统被分为以下五层：

core ──► domain ──► app ──► event ──► infra

Title

副作用驱动设计（EDD）评估标准文档

一、评估目的

本标准用于系统性评估使用 EDD（Effect-Driven Design）方法构建系统时的整体开发质量、结构表现、团队协作效率与可维护性，并与传统架构（如 MVC、DDD）进行对比分析。

该评估体系可用于：

• 架构选型前的决策辅助
• 项目试点后的复盘评估
• 构建自动化代码生成框架前的成熟度判定

二、评估维度总览

Effect-Driven Design 副作用驱动设计

一、从副作用说起

什么是副作用？

在编程中，副作用（Side Effect） 是指函数或操作除了返回值之外，对系统状态产生的任何可观察的改变。

// 纯函数 - 无副作用
fn calculate_price(quantity: u32, unit_price: f64) -> f64 {
    quantity as f64 * unit_price
}

// 有副作用的函数
async fn create_order(items: Vec<Item>) -> Result<Order> {
    let order = Order::new(items);
    database.insert(&order).await?;      // 副作用：数据库写入
    email.send_confirmation(&order).await?; // 副作用：发送邮件
    Ok(order)
}

Rust随笔（八）

今天来谈谈Rust里面的Sync和Send，在随笔七里面我们提到这两个概念，今天我们来详细的说一下。这两个trait是rust异步编程的主要基石之一。我们首先看看定义：

1. Send Send 表示一个类型的所有权可以安全地在线程之间转移。
2. Sync Sync 表示一个类型的不可变引用（&T）可以安全地在线程之间共享。 只有同时实现这两者，才能在多线程环境下共享数据，看着定义我们会感到有点疑惑，接下来我们用例子说明。

gitea与woodpecker的cicd环境

之前使用gitea与Jenkins构建出来一个ci/cd的环境，但是过程就像老太太的裹脚布一样又臭又长，而且Jenkins对于容器化的支持其实并不好，走了很多弯路，而 GitLab 占用的资源过多，不适合我的个人场景。换成 Podman + Woodpecker 之后，不仅资源占用小，也能专注项目本身，这就是我想要的简洁、高效的 CI/CD 环境。于是有了这一篇博客。

环境配置