基本上，我的应用程序就像stackoverflow一样，你登录和发布一些东西，其他人来和互动。
考虑DDD术语，并试图避免贫血模型，我现在面临这样的决定：我的User实体是否应该掌握创建任何更新后所需的知识+删除+检索他的帖子或我我应该回到旧的模式，我有一个“发布商业服务”，将获得UserDTO参考，PostDTO并做一切？
详细说明：
- 我相信我需要某种帖子服务，因为主页面需要列出所有帖子，管理员用户将能够删除任何帖子...
- 理论上，只有User实体（以及从中继承的其他实体）应该能够创建帖子
- 我不知道我将如何处理授权（想想阻止垃圾邮件发送者和其他人）
- 也许这应该是由User.CreatePost(postDTO)触发的域名服务？
答案 0 :(得分：5)
只是想问出你问题的一部分：
创建任何帖子更新+删除+检索
这表明DDD可能不是这个系统的正确答案。任何核心要求都是创建，读取，更新，删除的系统都没有调用DDD方法。事实上，DDD可能会妨碍您的成功实施 - 一个基本的CRUD系统可能会让您的生活更轻松。
DDD就是你想用域语言来思考的东西 - 用户不是“创建帖子”，他们是“提问”或“回答问题”。管理员不会“删除帖子”他们“存档帖子”。
“提出问题”的技术实现可能最终导致数据库记录变为“已创建”，但目标是将其向下推送到持久层，并使域名完全按照“普遍的语言”实现”
假设您正在使用DDD，我在考虑这种情况时使用的一种模式有助于在考虑问题和答案的核心域时避免使用非常抽象的User实体。
User实体适用于Identity管理有界上下文，您可以在其中跟踪身份验证/登录详细信息。但是，一旦您调查核心域，通常用户就会比一般User更具体和具体，因为他们在特定角色下与系统进行交互。例如您正在考虑提问和回答问题的用户。也许您还会有作为管理员的用户或管理员用户。
这些类型的用户中的每一种都将执行不同类型的活动。因此，有时明确地模拟每个角色是有帮助的 - 例如Poster实体，Moderator实体和Administrator实体。
您可以Poster.AskQuestion，Poster.AnswerQuestion，Moderator.Moderate等。
我有时强调 因为用户的角色不需要需要在模型中体现 - 角色只是访问控制/授权层的一部分，模型可以在当前用户被授权的假设下运行。
e.g。也许你的案例中的关键实体是MessageBoard，它有MessageBoard.AddPost方法。
然而，在您的情况下，可能是与帖子相关联的用户是域的核心部分 - 也许您将在用户身上驱动其他行为，作为他们的问题和回答习惯的一部分，例如改变他们的状态，或添加徽章或类似的东西。