DDD落地开发中如何处理不同角色对应post实体的逻辑差异

完全不需要按角色拆分目录重复编写Post相关代码。你对「不同上下文中Post应具备不同方法」的判断符合DDD的设计原则，二者的差异是限界上下文的边界差异，不是实体本身需要多份重复实现。

1. 先完成限界上下文划分 #

你当前的场景可以拆为两个独立的限界上下文，各自维护对应上下文内的Post模型：

• 内容管理上下文：对应管理员对Post的全生命周期操作，该上下文内的Post实体包含Create()、Update()、Delete()等领域方法，仅允许Admin角色调用
• 内容互动上下文：对应用户对Post的浏览、评论操作，该上下文内的Post为精简投影模型，仅保留标题、内容、发布时间等展示必需字段，无修改类方法，仅对外提供关联评论的能力。

2. 代码结构优化建议 #

不要按角色创建独立目录，可按如下方式组织避免重复：

• 领域层将Post的通用核心属性（ID、标题、内容、发布状态等不随操作角色变化的字段）抽取到共享内核中，两个上下文的Post模型按需引用/继承该通用模型，不需要重复编写属性定义
• 应用层按业务能力拆分服务：管理员的Post操作对应PostAdminService，普通用户的互动操作对应PostInteractionService，两个服务各自依赖所属上下文的Post模型，互不干扰
• 轻量化场景下可以不拆分Post模型，直接在领域方法内补充权限校验逻辑，执行操作前判断当前角色是否拥有对应权限即可

3. 避免按角色拆分的核心原因 #

• DDD的核心拆分依据是业务能力/限界上下文，而非操作角色，按角色拆分后会产生大量冗余代码，后续Post核心属性调整需要修改多份副本，维护成本会指数级上升
• 角色属于权限校验维度的概念，应该放到权限校验层（应用层拦截器、领域服务校验逻辑）处理，不应该侵入领域模型的拆分逻辑

内容的提问来源于stack exchange，提问作者Ngọc Nguyễn