朝着成为极客的目标迈进
副作用驱动设计（Effect-Driven Design, EDD）是一种以“副作用识别与组织”为核心的系统架构方法。它不以MVC、DDD等传统技术结构为起点，而以副作用的边界、风险和组织方式为第一性原则，构建适应变化、具备可观测性和可测试性的现代系统。
核心口号：副作用不可怕，不可控的副作用才可怕。
| 层级 | 内容 | 说明 |
|---|---|---|
core/ |
纯业务数据结构与逻辑 | 不允许副作用，可100%测试 |
domain/ |
行为语义接口定义（trait）（行为定义层） | 描述副作用语义，不绑定具体框架 |
app/ |
usecase编排层（这个其实应该是Service层） | 组合 trait、协调行为、返回结果+事件 |
infra/ |
具体实现，如 DB/API/Cache （这个是副作用实现层） | 所有副作用实现汇聚于此层 |
event/ |
事件定义与事件调度器 （这是副作用触发层） | 用于解耦外部副作用与主流程 |
| 代码模板结构： |
在 EDD 实践中，我们发现了一个关键矛盾：
// 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
| 层级 | 内容 | 说明 |
|---|---|---|
core/ |
纯业务数据结构与逻辑 | 不允许副作用，可100%测试 |
domain/ |
行为语义接口定义（trait）（行为定义层） | 描述副作用语义，不绑定具体框架 |
app/ |
usecase编排层（这个其实应该是Service层） | 组合 trait、协调行为、返回结果+事件 |
infra/ |
具体实现，如 DB/API/Cache （这个是副作用实现层） | 所有副作用实现汇聚于此层 |
event/ |
事件定义与事件调度器 （这是副作用触发层） | 用于解耦外部副作用与主流程 |
web/ |
控制器/handler层 （这是纯的外部调用了） | 请求转译、状态注入、回传 |
副作用驱动设计 (Effect-Driven Design, EDD)
副作用 (Side Effect)
纯化层 (Pure Layer)
在 Effect-Driven Design (EDD) 架构中，系统被分为以下五层：
core ──► domain ──► app ──► event ──► infra
本标准用于系统性评估使用 EDD（Effect-Driven Design）方法构建系统时的整体开发质量、结构表现、团队协作效率与可维护性，并与传统架构（如 MVC、DDD）进行对比分析。
该评估体系可用于：
| 类别 | 维度名称 | 评估对象 |
|---|---|---|
| 开发效率 | usecase 构建速度副作用处理复杂度 | 项目整体 & 单个功能开发过程 |
| 架构结构 | 模块边界清晰度副作用封装结构usecase聚合能力 | 模块代码组织、trait与event关系图 |
| 可测试性 | usecase 测试便利性副作用 mock 难度逻辑可观测性 | 单元测试覆盖率、测试代码复杂度 |
| 可演进性 | 新增行为/副作用代价重构路径稳定性支持复杂变更能力 | 版本迭代中usecase调整记录 |
| 对比适配 | 与DDD的概念重叠度替代或互补能力 | 概念抽象对照分析 |
在编程中，副作用（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)
}
sudo apt update
sudo apt install tlp tlp-rdw thermald
sudo systemctl enable tlp
sudo systemctl enable thermald
今天来谈谈Rust里面的Sync和Send，在随笔七里面我们提到这两个概念，今天我们来详细的说一下。这两个trait是rust异步编程的主要基石之一。我们首先看看定义：
Send 表示一个类型的所有权可以安全地在线程之间转移。Sync 表示一个类型的不可变引用（&T）可以安全地在线程之间共享。
只有同时实现这两者，才能在多线程环境下共享数据，看着定义我们会感到有点疑惑，接下来我们用例子说明。
之前使用gitea与Jenkins构建出来一个ci/cd的环境，但是过程就像老太太的裹脚布一样又臭又长，而且Jenkins对于容器化的支持其实并不好，走了很多弯路，而 GitLab 占用的资源过多，不适合我的个人场景。换成 Podman + Woodpecker 之后，不仅资源占用小，也能专注项目本身，这就是我想要的简洁、高效的 CI/CD 环境。于是有了这一篇博客。
提示
开发环境： debian 12 podman 4.3.1 podman-composer 1.0.3 rustc 1.87.0
所用容器镜像：
quay.io/podman/stable latest
docker.gitea.com/gitea 1.24.1-rootless
docker.io/library/debian stable-slim
docker.io/library/debian bookworm-slim
docker.io/woodpeckerci/woodpecker-server v3
docker.io/woodpeckerci/woodpecker-agent v3
docker.io/woodpeckerci/plugin-git 2.6.5
docker.io/library/rust 1.87.0
部署环境： debian bookworm-slim podman 4.3.1
在数字的海洋中，我们编织梦想的网络， 用代码的笔触，描绘未来的轮廓。
每一个字节跳跃，都是探索的脚步， 在技术的星空下，共同追寻知识的光芒。