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