日志记录逻辑应该放在 DDD 解决方案中的什么位置？答案

【问题标题】：Where should logging logic sit within a DDD solution?日志记录逻辑应该放在 DDD 解决方案中的什么位置？
【发布时间】：2010-06-25 14:57:08
【问题描述】：

我为我的 MVC 应用程序 [LogAttribute] 创建了一个自定义过滤器。动作方法用这个装饰，它有责任创建一个 LogEntry 对象以传递给某种类型的提供者 - ILoggerProvider。

我的问题是，ILoggerProvider 和它的实现应该放在哪里（我想在上面使用 DI 技术）？他们应该进入领域模型、UI 项目还是单独的类？

【问题讨论】：

【解决方案1】：

除非您的软件的主要功能是 Logging 或 Auditing，否则它应该是 Infrastructure LoggingService。

除非您的日志记录实现与您的域对象紧密耦合（我希望不是！），否则我建议使用完全独立的程序集。

【讨论】：

【解决方案2】：

出于几个原因，我通常认为 ILoggingProvider 应该位于域模型中。从后勤和健全的角度来看，您的域类可能需要引用记录器。从 DDD 的角度来看，鉴于 SOX 和我们所生活的世界，可以说日志记录是法规遵从性的核心域功能。

现在，这些实现绝对可以在您的基础架构项目中占据一席之地，无需将模型弄得乱七八糟。

【讨论】：

这是有道理的，因为监管机构正在对您的通用语言 (UL) 施加限制。特别是，“你应该记录这个和那个事件”的规定在你的模型中有一个对应的实体。法规可以是领域的一部分，并且凭借 UL，该模型获得了某种日志记录工件。

【解决方案3】：

由于日志记录与 UI 无关，这绝对是错误的地方。在我看来，域模型用于数据表示。所以我会在单独的班级甚至单独的项目中进行。

我有一个 MVC 应用程序，其中有一个单独的日志服务项目。在我的结构中，它位于最底层（数据访问），因为它直接记录到文件并且所有其他服务都在使用它。我还通过使用 MEF 框架在其上使用 DI。

这对我来说已经有一段时间了，从那以后我不想改变它。我有其他解决方案，但我在一段时间后跳过了，因为它们不像我当前的解决方案那样优雅。

希望对您的决定有所帮助。

【讨论】：