Php DDD和可指责的

你如何以DDD的方式处理可指责的情况？ 当然，我们可以忽略一些事情，但我认为当实体需要一些跟踪创建者、更新者、时间更新者/创建者时，它应该在类中实际对实体执行一些操作。 例如，我们有post和user，正确的方法是什么

$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);

对我来说，second更好，即使我们需要跟踪不直接应用于post的更改，例如：

$post->doSomethingWithPost();
$user->updatePost($post);

似乎应该责备的只是抛弃了一个重要的实体——在实体上管理某些事情的用户。 当然，我们不应该使事情过于复杂，但通常在实现可责备时，您将从中获取id的实体是登录用户，这对于有界上下文是不正确的。 这里是一些博客上下文，其中该上下文的用户更新帖子，而不是某个经过身份验证的用户

---

你对这个有什么想法？是否有一些我可能遗漏的类似问题？

您所有的示例似乎都没有考虑DDD原则。对我来说，第一个指标是$user变量的用法。在99%的情况下，这太笼统，无法真正捕获给定模型的意图。我认为有一些隐藏的概念必须首先明确。我的想法与注册管理员和管理员大致相同。至少这是我从中了解到的：

这里是一些博客上下文，其中该上下文的用户更新帖子，而不是某个经过身份验证的用户

另一个问题是，此上下文的用户如何不进行身份验证？你怎么知道他是谁

一般来说，在一个明确要求用户管理的应用程序中，我们通常会使用类似IdentityContext的内容作为支持子域。在不同的上下文中，我们还有其他模型，比如Author或blogradministrator，从IdentityContext中引用用户的身份UserId。有一些关于如何实现这一点的好例子

要回答如何跟踪谁更改了某些内容以及何时更改的问题，请执行以下操作：

这个概念也被称为可审计性，在系统的大多数与收入相关的部分中，当您的组织达到一定规模时，这实际上是必须的。在这个场景中，我实际上总是推荐一种事件源方法，因为它附带了可审核性电池

在您的情况下，将正在执行的UserId作为元数据捕获到WritePostCommand或ChangePostContentsCommand等命令，或者在RequestContext对象中使用UserId就足够了，该对象知道发送此命令的执行上下文，当该命令被发送时，是否允许该用户执行此用例

然后，正如评论中指出的那样，您可以在存储库或处理程序中使用此元数据将信息传递给需要的聚合，或者甚至可以将其发送到审核日志，以避免因此职责而污染您的域模型

注意：一般来说，我不会在您的域模型中使用DoctrineExtensions，如可责备。它们在很大程度上依赖于条令的事件系统，并且您不希望将您的模型绑定到基础架构问题中

---

亲切问候

讽刺的是，你首先创建了一篇文章，然后在新创建的文章上调用create方法……是的，我刚刚向案例展示了DDD方面的问题，并询问在现实世界中，应该是$user->createPost$Post或$Post=new Postnew Author$Post->create。这里的主要问题是关于可责备的。对我来说，可责备似乎是一个应用程序问题，在您的域模型中找不到，因此应该在域模型之外处理。使用直接的存储库实现，对创建者/更新者/更新时间/创建时间等的跟踪几乎是微不足道的。