Ent支付订单聚合领域建模与架构设计 - 第3节

3.1 什么是 Ent：不仅仅是 ORM

Ent 是 Facebook 开源的一款 Go 实体框架，它既是一个 ORM（对象关系映射）工具，更是一个 图数据建模与代码生成引擎。在 DDD 实践中，Ent 的核心价值在于：让领域模型与持久化层之间的映射变得显式、可追踪、可验证。

传统 ORM 通常以“表驱动”方式工作——先设计数据库表，再生成对应的结构体。Ent 则反其道而行之：以 Schema（模式）为中心，开发者用 Go 代码定义领域实体及其关系，Ent 自动生成类型安全的 CRUD 代码、迁移脚本和查询构建器。

💡 关键认知：Ent 不是“另一个 GORM”。GORM 是典型的“反射 + 约定”ORM，运行时通过反射推断字段和关系；Ent 是“代码生成 + 编译时检查”ORM，所有操作在编译期就确定了类型安全。在支付订单这类高一致性要求的聚合中，编译时检查能提前捕获大量字段拼写、类型不匹配问题。

3.1.1 Ent 与 ORM 的关系

维度 传统 ORM（如 GORM） Ent（代码生成 ORM）
建模方式 表驱动：先建表，再生成结构体 Schema 驱动：先写 Go 结构定义，再生成表
类型安全 运行时反射，字段名用字符串传递 编译时生成，字段名是类型安全的常量
关系处理 外键 + 预加载（Preload） Edge（边）显式定义，自动生成 Join 查询
迁移 自动迁移（可能丢失数据） 版本化迁移（可回滚、可审查）
DDD 适配度 低：聚合、值对象映射困难 高：支持嵌套结构、Edge 表达聚合关系
📌 支付订单场景：在支付订单聚合中，Order 与 OrderItem 是“聚合根→实体”关系，Order 与 Payment 是“聚合根→值对象”关系。Ent 的 Edge 机制可以精确表达这两种不同强度的关联，而传统 ORM 通常只能统一用外键处理。

3.2 Ent 的核心概念：Schema、Field、Edge

Ent 的建模体系由三个核心概念构成：Schema（模式定义）、Field（字段定义）、Edge（边定义）。理解这三者的关系，是掌握 Ent 领域建模的第一步。

Ent 核心概念关系图 Schema（模式） Field（字段） Edge（边） 定义属性 定义关系 代码生成产物：Entity 结构体 + CRUD 客户端 + 迁移 SQL 支付订单聚合中的映射示例 Schema: Order → Field: order_id, amount, status, created_at Edge: Order → OrderItem (O2M), Order → Payment (O2O)

3.2.1 Schema：领域实体的蓝图

Schema 是 Ent 建模的入口。每个 Schema 对应一个领域实体（在 DDD 中通常是聚合根或实体）。Schema 定义在 ent/schema/ 目录下，以 Go 结构体形式存在。

// ent/schema/order.go
package schema

import (
    "entgo.io/ent"
    "entgo.io/ent/schema/field"
    "entgo.io/ent/schema/edge"
)

// Order 是支付订单聚合根
type Order struct {
    ent.Schema
}

// Fields 定义订单的属性
func (Order) Fields() []ent.Field {
    return []ent.Field{
        field.String("order_id").Unique().Immutable(),
        field.Float("amount").Positive(),
        field.String("status").Default("pending"),
        field.Time("created_at").Immutable(),
    }
}

// Edges 定义订单与其他实体的关系
func (Order) Edges() []ent.Edge {
    return []ent.Edge{
        edge.To("items", OrderItem.Type),
        edge.To("payment", Payment.Type).Unique(),
    }
}
⚠️ 常见误区：不要把 Schema 等同于数据库表。Schema 是领域模型的映射，它包含的字段和边应该反映业务概念，而不是数据库优化策略。例如，支付订单的 amount 字段应该用 Float64 而不是 Decimal，因为领域层需要的是金额值，而不是数据库精度。

3.2.2 Field：定义实体的属性

Field 定义了实体包含哪些属性，以及每个属性的约束。Ent 提供了丰富的字段类型和修饰器，可以精确表达领域约束。

字段类型 Go 类型 常用修饰器 支付订单场景示例
field.String string Unique(), NotEmpty(), MinLen() order_id, user_id, currency
field.Float float64 Positive(), Min(), Max() amount, discount, tax
field.Time time.Time Immutable(), Default() created_at, paid_at, expired_at
field.Enum string Values(), Default() status (pending/paid/cancelled)
field.JSON []byte / struct Optional() extra_info, payment_details
💡 领域驱动设计建议：在定义 Field 时，尽量使用业务语义的修饰器。例如 Positive() 比 Min(0.01) 更能表达“金额必须为正”的领域规则。Ent 的修饰器会在代码生成时转化为验证逻辑，确保领域约束在持久化层也被强制执行。

3.2.3 Edge：定义实体间的关系

Edge 是 Ent 最强大的概念之一，它显式地定义了实体之间的关联关系。在 DDD 中，Edge 天然适合表达聚合内部的组成关系以及聚合之间的引用关系。

// ent/schema/order_item.go
package schema

import (
    "entgo.io/ent"
    "entgo.io/ent/schema/field"
    "entgo.io/ent/schema/edge"
)

type OrderItem struct {
    ent.Schema
}

func (OrderItem) Fields() []ent.Field {
    return []ent.Field{
        field.String("item_id").Unique().Immutable(),
        field.String("product_name").NotEmpty(),
        field.Int("quantity").Positive(),
        field.Float("unit_price").Positive(),
    }
}

func (OrderItem) Edges() []ent.Edge {
    return []ent.Edge{
        // 从 OrderItem 指向 Order，表示属于哪个订单
        edge.From("order", Order.Type).
            Ref("items").    // 对应 Order.Edges 中的 "items"
            Unique(),        // 一个 OrderItem 只属于一个 Order
    }
}

Edge 支持三种关系类型：

  • O2O（一对一）：如 Order → Payment，一个订单只有一个支付记录。
  • O2M（一对多）：如 Order → OrderItem，一个订单包含多个订单项。
  • M2M（多对多）：如 Order → Coupon（优惠券），一个订单可用多个优惠券，一个优惠券可被多个订单使用。

3.3 Ent 的代码生成与类型安全

定义完 Schema 后，Ent 通过命令行工具 entc 生成类型安全的代码。生成的代码包括：

  • 实体结构体：如 Order、OrderItem，包含所有字段和边。
  • CRUD 客户端：如 OrderClient，提供 Create()、Query()、Update()、Delete() 方法。
  • 查询构建器：如 OrderQuery，支持链式调用和预加载。
  • 迁移代码：自动生成建表、加索引、加外键的 SQL。
// 生成的类型安全查询示例
// 编译时检查字段名，不会出现运行时拼写错误
client.Order.
    Create().
    SetOrderID("ORD-2024-001").
    SetAmount(299.99).
    SetStatus("pending").
    SetCreatedAt(time.Now()).
    AddItem(item1, item2).  // 添加关联的 OrderItem
    Save(ctx)

// 查询时预加载关联
order, _ := client.Order.
    Query().
    Where(order.OrderID("ORD-2024-001")).
    WithItems().           // 预加载 OrderItem
    WithPayment().         // 预加载 Payment
    Only(ctx)
🔧 工程实践：在支付订单系统中，建议将 Ent 生成的客户端封装在 Repository 层内部，领域层只依赖接口（如 OrderRepository），不直接依赖 Ent 生成的类型。这样可以在不修改领域逻辑的前提下，切换持久化实现。

3.4 本章小结

  • Ent 是代码生成 ORM：与运行时反射的 ORM 不同，Ent 在编译期生成类型安全的代码，适合高一致性要求的支付领域。
  • Schema 是领域模型的入口：每个 Schema 对应一个领域实体，Field 定义属性，Edge 定义关系。
  • Edge 表达聚合关系：O2O、O2M、M2M 三种关系类型可以精确映射 DDD 中的聚合组成和跨聚合引用。
  • 代码生成提升生产力：Ent 自动生成 CRUD、查询构建器和迁移脚本，减少重复代码，降低手写 SQL 的错误率。
← 上一章 📖 返回目录 下一章 →