design-patterns - DDD审计？域层还是存储库层？

Question

我目前正在开发的应用程序要求在另一个表中审核数据库中的每个内容:

例如:员工表有 EmployeeAuditTable

我一直在争论我应该把审计功能放在哪里!遵循 DDD 的任何人都可以向我提供他们的建议和意见。

我想到的选项如下
1.) 当“存储库”调用保存更改时，我应该从存储库执行审计逻辑(让存储库不仅保留更改而且还保留审计详细信息，这是一种糟糕的设计/做法吗？甚至是好的做法吗？从存储库中调用服务(在本例中为 IauditService ))

示例 1:

public class EmployeeRepository : IRepository
{
    DbContext _db;
    IAuditService _auditService;

    EmployeeRepository(IAuditService auditService)
    {
      _auditService = auditService
    }
    void Update(Employee empl)
    {
        // Update Employee with dbcontext entity framework

        // Perform Audit using AuditService
    }

   void SaveChanges()
   {
      // Call save changes on dbcontext
   }

}

2.) 我应该在我的应用程序服务中调用 IauditService

示例 2:

public class EmployeeService
{
   IAuditService _auditService;
   IUnitOfWork   _unitOfWork;
   IEmployeeRepository _repository;

   EmployeeService(IAuditService auditService, IUnitOfWork  unitOfWork, IEmployeeRepository repo)
   {
       _auditService = auditService;
       _unitOfWork= unitOfWork;
       _repo  = repo;
   }

   void UpdateEmployee(int id, string name, int age)
   {
      // Get Employee

      // Update Employee

      // Audit Changes

      // Commit Transaction

   }


}

Answer 1

我知道您希望对数据库中的所有对象进行审计跟踪，但我不会监督您问题的全部复杂性。不太清楚你的Employee和您的 EmployeeAuditTable看起来像，但选择的命名约定表明它包含与员工表相同的列。

审计可以并且经常被认为是一个“交叉关注点”。当您有“应审核所有更改”等要求时尤其如此。如果审计不是业务问题(或用例或您称之为的任何内容)，您不应该将它放在您的实体、服务或存储库中；如果仅仅是因为忘记在审计中编码是非常非常容易的，会给你留下不正确的审计线索——有些人认为这比根本没有审计线索更糟糕。

形成您的代码示例，我看到您正在使用一个工作单元。我想象在

// commit transaction

您提交工作单元跟踪的更改:

// commit transaction
_unitOfWork.Commit();

同样，它提交工作单元跟踪的更改。这是您的审计 Hook 点，它不需要在您的任何服务、实体或存储库中进行编码。

事实上，当你使用像 (N)Hibernate 这样的 ORM 框架时，你可以让 ORM 为你跟踪变化(它会为此 Hook 到它的工作单元中)，例如参见 the wiki page "creating an audit log using events"或 Envers NHibernate 的审计框架，也在 this answer on SO 中讨论过.我强烈建议您阅读 Envers 文档，即使您实现自己的审计解决方案。