俱乐部系统领域驱动设计3

领域驱动设计（DDD）建模：俱乐部网络应用

---

子域识别

1. 核心子域

   • 俱乐部管理：俱乐部的创建、配置（可见性/加入方式）、管理员任命、成员管理（审批/踢出）。
   • 成员互动：公告发布、话题讨论、相册上传等核心用户活动。
   • 扩展功能管理：为特定俱乐部类型（如拍卖、游戏）定制功能的能力。

2. 通用子域

   • 用户身份认证：用户注册、登录、基础信息管理。
   • 通知系统：发送成员加入、内容更新等通知。
   • 文件存储：照片/文件上传的通用存储服务。

3. 支撑子域

   • 权限控制：验证用户操作权限（如管理员审批、内容删除）。
   • 审核机制：内容敏感词过滤或人工审核（非核心但必要）。
   • 数据分析：统计俱乐部活跃度、成员增长（支撑运营决策）。

---

限界上下文设计

限界上下文	职责	与其他上下文的关系
Club Management	俱乐部创建、配置、管理员任命、成员状态管理	依赖 User、Authorization
Content	公告、话题、相册等内容的发布与管理	依赖 Membership、Authorization
Membership	成员加入、角色分配（发起者/管理员/成员）、状态管理（正常/禁止）	依赖 User、Club Management
Extension	扩展功能（拍卖、游戏）的启用与生命周期管理	依赖 Club Management
User	用户注册、登录、基础信息维护	被多个上下文依赖
Authorization	权限验证（如”仅管理员可踢人”）	被 Content、Membership 依赖

---

领域模型设计

1. Club Management 上下文

• 聚合根: Club

  • 属性：ClubId（唯一标识）, Title, Description, FounderId（发起者ID）
  • 值对象：
    • VisibilitySetting（值对象）：{ Public, Private }
    • JoinMethod（值对象）：{ Open, InviteOnly }
  • 领域事件：
    • ClubCreated：俱乐部创建时触发，初始化配置。
    • AdminAppointed：任命管理员时触发，传递 UserId 和 ClubId。

• 实体: ClubAdmin

  • 属性：AdminId, UserId, ClubId, AppointmentDate

2. Membership 上下文

• 聚合根: ClubMember

  • 属性：MemberId, UserId, ClubId, Role（枚举：Founder/Admin/Member）, Status（枚举：Active/Banned）
  • 领域事件：
    • MemberJoined：用户加入时触发。
    • MemberBanned：成员被禁止时触发。
    • RoleChanged：角色变更时触发（如普通成员升为管理员）。

• 策略模式：

  • 根据 Club.JoinMethod 实现不同加入策略（OpenJoinStrategy 或 InviteOnlyJoinStrategy）。

3. Content 上下文

• 聚合根: Post（公告/话题的基类）
  • 属性：PostId, ClubId, AuthorId, Content, Timestamp
  • 子类：
    • Announcement（公告）
    • DiscussionTopic（讨论主题）
• 聚合根: PhotoAlbum
  • 属性：AlbumId, ClubId, Photos（值对象列表）
  • 值对象：Photo = { PhotoId, Url, UploaderId, Timestamp }
  • 领域事件：
    • PhotoUploaded：照片上传时触发。

4. Extension 上下文

• 聚合根: ClubExtension
  • 属性：ExtensionId, ClubId, Type（枚举：Auction/Game/…）
  • 实体：Auction = { Item, StartTime, Bids }, Game = { SessionId, Players }
  • 领域事件：
    • ExtensionEnabled：扩展功能启用时触发。

5. User 上下文

• 聚合根: User
  • 属性：UserId, Username, Email, JoinDate

6. Authorization 上下文

• 领域服务: PermissionService
  • 方法：CanBanUser(UserId, ClubId) → 验证用户是否有权限踢人。

---

关键领域事件交互

1. ClubCreated（Club Management 发布）→
   • Membership 订阅：自动将发起者添加为 ClubMember（角色：Founder）。
2. AdminAppointed（Club Management 发布）→
   • Membership 订阅：更新目标用户的 ClubMember.Role。
3. MemberJoined（Membership 发布）→
   • Content 订阅：允许新成员发布内容。
   • Notification 订阅：发送欢迎通知。

---

模型示意图

                          +-----------------+
                          | Club Management |
                          +--------+--------+
                                   | 发布 ClubCreated
                                   ▼
+----------------+        +--------+--------+
| User Context   +------->| Membership      | ← 接收 AdminAppointed
+----+-----------+        +--------+--------+
     |                           | 发布 MemberJoined
     |                           ▼
     |                  +--------+--------+       +----------------+
     +----------------->| Content        +------>| Extension      |
                        +--------+--------+       +----------------+
                                 ↑
                     +-----------+-----------+
                     | Authorization Service |
                     +-----------------------+

设计原则总结

1. 高内聚低耦合：每个限界上下文封装独立业务逻辑（如 Content 仅处理内容发布）。
2. 显式边界：通过领域事件跨上下文通信（如 MemberJoined 事件驱动内容权限更新）。
3. 扩展性：
   • 通过 ClubExtension 聚合根支持未来功能扩展。
   • 策略模式实现灵活的成员加入逻辑。
4. 安全性：Authorization 上下文统一处理权限，避免散列逻辑。

此设计确保核心业务（俱乐部管理与成员互动）高度聚焦，同时通过清晰的上下文边界维护系统的可维护性与可扩展性。