fed notes

Appearance

domain ​

my：domian 是纯粹的业务描述，没有技术细节的描述。

如果脱离数据库 / Redis / HTTP，还成立吗？

是 业务规则（domain）还是实现过程（flow）？  
业务规则是约束（constraint），实现过程是手段（mechanism）

如果我换技术实现，这段逻辑还存在吗？

DDD 就是先抽象并收拢核心业务逻辑，让模型严格对齐真实业务规则； 再基于这个稳定的领域模型，推导数据结构、行为逻辑和对外接口。 —— 豆包

DDD 的本质是围绕业务构建清晰的领域模型，将业务规则内聚在模型中，并通过应用层组织用例，对外通过 API 暴露能力。 —— GPT

理解业务 → 建立模型 → 用模型约束行为 → 技术只是承载

模型负责“约束世界”，流程负责“推动世界”

例子1 ​

注册用户 → 需要发送验证码

domain

我要“发送验证码”

技术实现

我要用 SMTP 发送验证码

建模 ​

模型是“长出来的”，不是“一次设计出来的”，是持续迭代的

建模是将业务逻辑中的核心概念、行为和约束内聚到领域模型中；
最终代码由领域模型表达规则，由应用层编排业务流程。

  1. 业务里“有什么东西”（名词）
  • 用户（User）
  • 订单（Order）
  • 权限（Permission）
  1. 它们“能做什么”（行为）
  • 用户可以“禁用”
  • 订单可以“支付”“取消”
  1. 做这些事“有什么规则”（约束 / Rule）
  • 已支付订单不能再取消
  • 禁用用户不能登录

“业务规则内聚”： 规则必须写在模型里

go
// 规则被封印进 Order 这个模型
func (o *Order) Pay() error {
    if o.status != Pending {
        return ErrInvalidState
    }
    o.status = Paid
}

流程 → 编排 ​

Flow

现有鸡还是蛋 ​

  • 法律（Domain）：规定什么是合法/非法
  • 执法流程（Flow）：警察怎么抓人、法院怎么审

是流程决定法律吗？

但是代码不是一蹴而就，大多情况是编写流程，梳理 Domain

业务需求通常以流程形式出现，但在实现过程中，需要将流程中的规则抽取并沉淀为 Domain 模型，由 Domain 反过来约束流程。

需求（流程） → 写代码 → 发现规则 → 抽进 Domain → 重构流程