你如何以DDD的方式处理责任？ 当然，我们可以忽略一些事情，但我认为当实体需要一些跟踪（创建者，更新者，时间更新/创建）时，它应该在实际上对实体执行某些操作的类中。 例如，我们有帖子和用户，这是正确的方法吗？
$post = new Post();
$post->create(); // here we can set some created_id and
other attributes by using mixins or traits like some fw do
或者更好的是这样：
$user->createPost($post);
$user->update($post);
至于我，第二个更好，即使我们需要跟踪不适用于直接发布的更改，例如：
$post->doSomethingWithPost();
$user->updatePost($post);
似乎责备只会抛出一个重要的实体 - 管理实体上某些事物的用户。 当然，我们不应该过分复杂化，但通常在实施可责备时，您将获得id的实体是登录用户，这对于有界上下文是不正确的。 这是一些博客上下文，其中此上下文的用户更新帖子而不是一些经过身份验证的用户。
你对这个问题有什么看法？是否有一些我可能错过的类似问题？
答案 0 :(得分：0)
您的所有示例似乎都没有考虑到DDD原则。我的第一个指标是使用$user变量。在99％的情况下，这太过于通用，无法真正捕获给定模型的意图。我认为首先必须明确隐藏的概念。我认为RegisteredAuthor和Administrator是一致的。至少我能理解的是：
这是一些博客上下文，其中此上下文的用户更新帖子而不是某些经过身份验证的用户。
另一个问题是这个背景的用户如何能够＃34;没有经过身份验证？你怎么知道他是谁？
通常，在明确要求用户管理的应用程序中，我们通常会使用 IdentityContext 作为支持子域。在不同的上下文中，我们还有其他模型，例如Author或BlogAdministrator，其中包含来自IdentityContext的用户身份（UserId）的引用。 The Red Book有一些关于如何实现它的很好的例子。
要回答关于如何跟踪更改内容以及何时更改的问题：
此概念也称为可审计性，在您的组织达到一定规模后，系统中大多数收入相关部分实际上都是必须的。在这种情况下，我实际上总是建议使用事件采购方法，因为它附带了可审计电池。
在您的情况下，将执行UserId作为元数据捕获到WritePostCommand或ChangePostContentsCommand等命令或使用<{1}}实际上就足够了> RequestContext 对象知道执行上下文（谁发送此命令，何时发送，是否允许此用户执行此用例）。
然后，您可以在评论中指出Alexander Langer，只需在您的存储库或处理程序中使用此元数据将信息传递给需要它的聚合，或者甚至可以将它们发送到审核日志不要用这个职责污染您的域模型。
注意：通常我不会在您的域模型中使用 DoctrineExtensions ，例如 Blameable 。他们严重依赖于Doctrine的事件系统，您不希望将您的模型与基础设施问题联系起来。
亲切的问候