日誌邏輯應該放在DDD解決方案的哪個位置？

Question

我爲我的MVC應用程序[LogAttribute]創建了一個自定義過濾器。操作方法用這個裝飾，它有責任創建一個LogEntry對象來傳入某種類型的提供者 - ILoggerProvider。

我的問題是，應該在哪裏ILoggerProvider和它的實施坐（我會想要使用DI技術）？他們是否應該進入領域模型，UI項目或單獨的課程？

Answer 1

由於日誌記錄與UI無關，因此這是錯誤的地方。 在我看來，領域模型是用於數據表示的。 所以我會在一個單獨的課程或甚至一個單獨的項目中做到這一點。

我有一個MVC應用程序，我有一個記錄服務的單獨項目。在我的結構中，它處於最底層（數據訪問），因爲它直接記錄到文件並且所有其他服務正在使用它。我也使用MEF框架使用DI。

這對我來說一直很好，而且從那以後我不想改變它。 我有一段時間後跳過了其他解決方案，因爲它們不像我當前的解決方案那樣高雅。

希望能幫助你做出決定。

Answer 2

我一般認爲ILoggingProvider應該位於領域模型中有幾個原因。從物流和理性角度來看，您的域類可能需要引用記錄器。從DDD的角度來看，考慮到SOX這樣的世界以及我們所居住的世界，人們可以爭辯說日誌記錄是法規遵從的核心領域特徵。

現在，這些實現絕對可以坐在您的基礎設施項目中，不需要混淆所有這些模型。

Answer 3

除非你的軟件的主要功能是日誌或審計，它應該是一個基礎設施LoggingService。除非你的日誌實現與你的域對象（我希望不是！）緊密耦合，否則我會建議一個完全獨立的程序集。