本文探讨在 go 语言 ddd 架构中，如何合理复用已有的领域模型（如 people）作为关联实体（如 tenant），避免代码重复与循环依赖，同时保持边界上下文清晰、接口职责明确。
本文探讨在 go 语言 ddd 架构中，如何合理复用已有的领域模型（如 people）作为关联实体（如 tenant），避免代码重复与循环依赖，同时保持边界上下文清晰、接口职责明确。
在 Go 的 DDD 实践中，模块间共享核心领域模型是常见但易出错的场景。以 People 和 Apartment 两个限界上下文（Bounded Context）为例：Apartment 需要管理 Tenant，而 Tenant 在业务语义上是 People 的一种角色（Role），而非独立实体——此时若为 Apartment 包复制一份 People 结构体，不仅违反 DRY 原则，更会破坏单一事实源（Single Source of Truth），导致数据不一致与维护成本飙升。
✅ 正确做法是分层解耦 + 组合复用 + 显式角色建模：
1. 提取共享模型到独立 models 包
将领域内可复用的核心结构体（如 Person）抽离至 internal/models（或 domain/models），不绑定具体业务逻辑：
// internal/models/person.go
package models
type Person struct {
ID uint64 `json:"id"`
Name string `json:"name"`
Email string `json:"email"`
CreatedAt time.Time `json:"-"`
}⚠️ 注意：
models包仅含纯数据结构（POGO），不含方法、验证逻辑或数据库标签（ORM 标签应放在 infra 层），确保其被多个上下文安全引用。
Golang Spf13 Viper下载Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
2. 使用组合而非继承定义角色语义
Tenant 不是 People 的子类，而是「拥有租客角色的 Person」。通过结构体嵌入（composition）实现语义扩展：
// internal/models/tenant.go
package models
type Tenant struct {
Person // 嵌入 Person，复用全部字段
ApartmentID uint64 `json:"apartment_id"` // 租赁关系专属字段
LeaseStartDate time.Time `json:"lease_start_date"`
IsActive bool `json:"is_active"`
}这样 Tenant 天然具备 Person 的所有能力（如 t.Name, t.Email），同时可扩展上下文专属属性，且无需类型转换或冗余复制。
3. 服务层按职责分离，接口下沉至 domain 层
-
接口定义统一置于
domain包（如domain/people_service.go），供各上下文实现或消费：// domain/people_service.go package domain
type PeopleService interface { GetByID(id uint64) (models.Person, error) Update(p models.Person) error Search(query string) ([]*models.Person, error) }
- `People` 上下文提供具体实现（如 `people/service.go`），返回 `*models.Person`；
- `Apartment` 上下文**不实现 `PeopleService`，而是依赖其接口**，通过 DI 注入使用：
```go
// apartment/service.go
type ApartmentService struct {
peopleSvc domain.PeopleService // 依赖抽象，非具体实现
repo ApartmentRepository
}
func (s *ApartmentService) GetTenant(personID uint64) (*models.Tenant, error) {
p, err := s.peopleSvc.GetByID(personID) // 复用 PeopleService
if err != nil {
return nil, err
}
return &models.Tenant{
Person: *p, // 直接构造 Tenant
// ... 其他字段初始化
}, nil
}4. 关键原则与避坑指南
- ❌ 禁止跨包直接引用实现（如
people.Service），只依赖domain层接口； - ❌ 不在
Apartment包内定义Tenant的 CRUD 接口——租客的「人」属性属于People上下文，Apartment只负责「租赁关系」管理； - ✅ 若需租客专属操作（如
TerminateLease()），应在Apartment上下文内定义新接口（如TenantLeaseService），内部调用PeopleService+ 自身仓储； - ✅ 所有跨上下文调用应通过接口+依赖注入完成，确保编译期解耦，便于单元测试与未来替换（如将
PeopleService替换为外部 API 客户端）。
综上，DDD 在 Go 中的成功落地不在于机械分包，而在于以领域语义驱动结构设计：共享模型归于 models，行为契约归于 domain，具体实现归属各自上下文，再通过组合与接口协作。这既保障了领域一致性，又为演进留出弹性空间。
