领域驱动设计如何在不同的有界上下文中显示审计属性？答案

【问题标题】：Domain Driven Design How to display audited attributes in different bounded contexts?领域驱动设计如何在不同的有界上下文中显示审计属性？
【发布时间】：2018-11-14 06:33:42
【问题描述】：

我们目前正在处理一个包含大量限界上下文的大型项目，其中一个用于身份和访问控制，它包含用户、角色实体。用户登录后，他可以使用任何其他模块（Bounded Contexts），我的问题->我们需要显示有关在不同有界上下文中创建或更新数据的用户的信息，例如，我们需要显示审核属性，例如ModifiedBy、CreatedBy 用户对于此类问题，我有两种解决方案：-

跨界上下文共享用户、角色
使用优化的 SQL 视图从有界上下文中获取聚合数据请注意，我使用单个数据库，但每个有界上下文使用不同的 sachems

【问题讨论】：

跨模块共享用户和角色是很正常的。我不确定这里有什么问题？这不能完全满足您的需求吗？
@yo2011 此信息是否应该始终与身份 BC 同步，或者它是执行操作时用户的快照（应该更容易实现）？
@guillaume31 应该每次都同步

标签： c# domain-driven-design audit-trail

【解决方案1】：

在 DDD 中，当您需要使用模型（如用户）从一个限界上下文 (BC) 到另一个限界上下文时，您应该使用 Anti-corruption layer。这意味着您不能简单地使用相同的模型，而是使用简化的模型，即具有更少的属性并且它必须是不可变的（只读）。

因此，如果用户是 IAC BC 中的实体，具有许多属性和行为（读取和写入），则在远程 BC 中它是 Value object，即只有其 ID 和 Name 为只读属性。 ACL 负责将远程实体转换为可以在本地 BC 中安全使用的本地值对象。

根据您的架构，ACL 可以使用CRON 作业来实现，定期更新来自远程实体的本地值对象，或者可以在事件驱动架构（CQRS、事件源）的情况下对远程事件做出反应。您甚至可以跟踪远程数据库的 oplog 以获得几乎即时的更新。

因此，每个 BC 都应该有自己的数据，并且其中的服务应该能够独立运行。如果一个 BC 中的服务出现故障，则另一个 BC 中的服务应该继续工作。将 BC 视为模块。

有些人将用户界面视为不同的 BC。因此，在这种情况下，optimized SQL views 可以存在于这个单独的 BC 中并充当具有内置 ACL 的模型。但是，它不能单独运行。它还将其他 BC 耦合在一起，强制您在所有 BC 中使用相同的数据库类型甚至实例。

【讨论】：