我对跟踪活动及其所属位置有疑问。
使用我的许多域命令，您可能还希望跟踪用户对特定上下文或对象所做的活动和所做的修改。
例如： 假设我们有一个项目域/上下文，可以在其中创建和编辑项目。用户将向api发出请求以执行此操作。我们可能想跟踪谁创建了一个项目以及对其进行了修改。
在典型的CRUD模型中，您可能会在域对象/表中找到created by字段
使用DDD将活动包含在域对象中时，感觉不对。活动日志感觉就像是跨多个边界的常规服务？拥有谁更改了域对象中内容的活动日志是否正确。没有它，它会感觉很干净而且专注。活动日志似乎特定于应用程序案例，而不是域？
所以： 活动跟踪应该在域对象中吗？ 如果不是这样，您将如何在一个命令/请求中进行处理。我不断听到人们说您应该只在命令/请求中触摸1个边界。
答案 0 :(得分：1)
我会将此活动日志视为其他任何数据。您将把它与周围的业务逻辑放在一起。为什么首先需要此信息？您的items context是否要实现需要活动日志的业务逻辑？如果不是，那我就说它不属于那种情况。
如果您要通过此日志尝试实现的数据分析需要在多个上下文中进行活动，那么我想说的是从您的业务操作中发布事件（每次用户对其中一个上下文执行操作时）您的活动跟踪上下文会听取他们的意见并以实现此目的的方式存储活动。
如果相反，您的项目上下文需要根据过去的活动应用某种逻辑，然后将其以允许您实现此业务逻辑的格式保存在该上下文中。
您实际上可能同时需要两者。某些上下文可能只是发布事件，而不存储活动，而其他上下文可能发布事件，并根据自己的内部需求跟踪活动。