本文探讨在 go 语言 ddd 架构中，如何避免重复定义相似实体（如 people 与 tenant），通过模型解耦、结构嵌入和边界上下文协作实现模块间安全复用。

本文探讨在 go 语言 ddd 架构中，如何避免重复定义相似实体（如 people 与 tenant），通过模型解耦、结构嵌入和边界上下文协作实现模块间安全复用。

在 Go 的 DDD 实践中，模块间的依赖不应通过复制代码或强耦合实现，而应基于限界上下文（Bounded Context） 和 领域模型的正交设计 来组织。以 People 和 Apartment 模块为例：Tenant 并非独立的业务实体，而是 People 在租赁场景下的角色视图（Role-based View）——它不拥有独立生命周期或业务规则，仅表示某人在特定上下文中的职责。因此，正确的做法是复用而非复制。

✅ 推荐架构分层方案

1. 统一领域模型层（models/）
   将核心领域对象（如 Person, Apartment）及其值对象、枚举等提取至独立包 models，供所有上下文引用：

   // models/person.go
   package models
   
   type Person struct {
       ID    uint64 `json:"id"`
       Name  string `json:"name"`
       Email string `json:"email"`
   }
   
   // models/tenant.go —— 不是新实体，而是组合 + 行为扩展
   type Tenant struct {
       Person        // 嵌入复用，语义清晰且零成本
       ApartmentID   uint64 `json:"apartment_id"`
       LeaseStart    time.Time `json:"lease_start"`
   }

2. 服务接口与实现分离（遵循 DDD 的防腐层原则）

   

   Golang Spf13 Viper

   Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。

   下载
   • 接口定义放在 interfaces/ 或各模块的 contract/ 子包中（不跨包共享实现）；
   • PeopleService 接口由 people 模块定义并实现，apartment 模块仅依赖其接口（通过依赖注入传入），而非具体类型：

     // people/contract/service.go
     type PeopleService interface {
       GetByID(ctx context.Context, id uint64) (*models.Person, error)
       Update(ctx context.Context, p *models.Person) error
     }

   // apartment/service/tenant_service.go type TenantService struct { peopleSvc PeopleService // 依赖抽象，非具体实现 repo TenantRepository }

3. 专用协调模块（tenants/）处理跨上下文逻辑
   当 Apartment 需要管理租户生命周期（如签约、退租、租金计算），应新建限界上下文 tenants，它：

   • 引入 models.Person 和 models.Apartment；
   • 组合 people.Repository 和 apartments.Repository；
   • 实现专属业务逻辑（如 AssignTenantToApartment()），不暴露底层 CRUD 方法给其他模块。

⚠️ 关键注意事项

• 禁止“复制粘贴式建模”：为 Tenant 单独定义与 Person 相同字段的结构体，会引发数据一致性风险、维护成本倍增，并违背 DDD “单一事实来源” 原则。
• 接口归属明确：PeopleService 接口应仅由 people 模块声明和实现；apartment 模块通过 import 引用该接口（Go 的接口是鸭子类型，无需导入实现包），但绝不定义同名接口副本。
• 领域事件驱动通信：若 Apartment 需响应 Person 状态变更（如身份证更新），应通过发布 PersonUpdatedEvent，由 tenants 模块订阅处理，避免直接调用服务。
• 数据库映射隔离：Tenant 在数据库中可作为关联表（tenants 表含 person_id, apartment_id），其结构由 tenants 模块负责映射，people 模块完全 unaware。

✅ 总结

DDD 在 Go 中的成功落地，关键在于以业务语义划分模块，以组合代替继承，以接口契约约束依赖，以新上下文封装跨域逻辑。Tenant 是 Person 的角色化延伸，不是平行实体；tenants 包是解决耦合问题的正确抽象层，而非妥协的“胶水代码”。坚持这一原则，才能让模块真正高内聚、低耦合，支撑长期演进。