ddd-module-pattern

DDD 模块模式

“模块应反映领域概念，而非技术关注点” — Eric Evans，《Domain-Driven Design》（2003）

核心原则

领域层的包名是通用语言的一部分。

问题：技术驱动的包组织方式

domain/
  entities/           ← ❌ 技術的分類
    Order.java
    Customer.java
  value-objects/      ← ❌ 技術的分類
    Money.java
    OrderId.java
  services/           ← ❌ 技術的分類
    OrderService.java

问题	影响
看不出领域结构	仅凭包结构无法了解业务形态
内聚性降低	相关概念散落在不同文件夹中
变更影响范围扩大	更改一项功能就要跨越多个文件夹

解决方案：领域驱动的包组织方式

domain/
  order/              ← ✅ ドメイン概念
    Order.java
    OrderId.java
    OrderItem.java
  customer/           ← ✅ ドメイン概念
    Customer.java
    CustomerId.java
  pricing/            ← ✅ ドメイン概念
    PricingPolicy.java
    Money.java

优点	效果
领域可视化	包列表 = 领域的主要概念
高内聚	相关类型集中在同一包中
局部变更	功能变更可在一个包内完成

检测模式

应避免的包名（领域层）

❌ entities/
❌ value-objects/ (valueobjects/, vo/)
❌ aggregates/
❌ services/
❌ interfaces/
❌ impl/
❌ dto/
❌ domain/types/
❌ domain/core/

评审检查清单

1. 包名测试：业务人员能理解吗？

   • ✅ order、billing、inventory → 业务术语
   • ❌ entities、services、impl → 技术术语

2. 内聚性测试：它们属于同一业务上下文吗？

   • ✅ 在 order/ 中放置 Order、OrderItem、OrderId
   • ❌ 在 entities/ 中放置 Order、Customer、Product

3. 变更影响测试：一项业务需求会涉及多少个包？

   • ✅ 1-2 个包
   • ❌ 3 个或更多包

重构步骤

Step 1：提取领域概念

現状分析:
- Order, OrderId, OrderItem → 「注文」概念
- Customer, CustomerId → 「顧客」概念
- Money, PricingPolicy → 「価格設定」概念

Step 2：确定包边界

order/
customer/
pricing/

Step 3：移动并更新引用

将类型移至新包，并更新 import 语句。

Step 4：确认依赖方向

✅ order → pricing (注文が価格計算を使う)
❌ pricing → order (循環の可能性)

各语言指南

详情请参阅 references/language-guides.md。

例外与注意事项

共享内核（Shared Kernel）

多个领域共用的基本类型可以放在共享包中：

domain/
  shared/           ← 許容される例外
    Money.java
    DateRange.java
  order/
  customer/

不过，shared/ 的膨胀是需要重新审视设计的信号。

基础设施层遵循不同规则

领域层以外也可以采用技术驱动的包组织方式：

infrastructure/
  persistence/      ← 技術的分類OK
    jpa/
    redis/

小型领域

少于 10 个类型时，使用单层结构即可。超过后请考虑使用子包。

参考文献

• Evans, Eric. “Domain-Driven Design”（2003），第 5 章：模块
• Vernon, Vaughn. “Implementing Domain-Driven Design”（2013），第 9 章：模块

相关技能（建议一并阅读）

使用此技能时，也请参阅以下技能：

• package-design：模块设计的基础包设计原则
• clean-architecture：放置领域模块的分层结构
• domain-building-blocks：模块内构件的设计