我有一个会议对象：
Meeting{id, name, time, CreatedBy, UpdatedBy}
和一个
MeetingAssignee{id, MeetingID, EmployeeId, CreatedBy, UpdatedBy)
会议，作为聚合根，有一个方法 AssignEmployee。
我正要在调用 AssignEmployee 时将当前用户传递给 Meeting 对象，以便它可以相应地更新其审计字段。
但这似乎不对——是吗？显然，我可以公开审计字段并在以后更改它们 - 也许在服务级别？
每个人更新这些字段的其他首选方法是什么？
请注意：我们使用的不是 Nhibernate，而是一个自定义的 ORM，它没有任何自动功能。
谢谢。
审计和日志记录很有趣，因为它们通常在应用程序的任何地方都需要，并且它们都是要求（记录是OP 人员的要求）。
在不了解您的模型的情况下，并且由于必须要求进行审核，因此我会将当前用户传递给AssignEmployee那里，而不是在那里显示一行，而是AuditBlahBlahBlah添加一个事件（可能是 MeetingUpdated 或 AssigneeAdded ...您会找到一个好名字）并且该事件被分派到进行审计的类。通过这种方式，Meeting 类对审计一无所知，并为审计目的调度业务事件（在我看来，这非常 DDDish）。
我想知道其他人会怎么说（希望我能学到新东西！）
考虑使用领域事件。
你的领域模型中所有有趣的事情都应该引发一个事件，大声喊出刚刚发生的事情。从外部，只需附加将它们转储到数据库或其他地方的日志处理程序。
这样 - 您不需要使用某种 IAudiService 来搞乱您的域。
更好的是——域模型可以使用事件作为一种在自身内部进行通信的方式。
为了说明为什么这是一个好主意 - 想象我们正在描述早晨、日出和鲜花的域模型。
告诉所有的花朵应该开放，是太阳的责任吗？并不真地。太阳只需要足够明亮（引发事件），光必须传播到地球（必须有某种基础设施使事件成为可能），花朵必须在接收光时自己做出反应（其他领域模型应该处理事件）。
另一个类比 - 驾驶员有责任查看交通灯的颜色。
您可以在持久化或更新实体时从服务层调用审计服务，审计服务已被注入任何需要审计功能的服务，并尽快持久化新创建的实体。
我看到很难确定审计的方式和时间，特别是如果您的实体在被持久化之前的某个时间作为可用实体存在于系统中。即使它们在被持久化之前存在了一段时间，也许您可以创建内存审计数据，包含它们的创建细节，然后在实体最终持久化时持久化。还是将 created-by、created-on、modified-by、modified-on 等数据设置为实体中的私有字段，并在实体持久化时将其写入审计日志？
我会对权衡取舍感兴趣。
我认为审计属性不是您的域模型的关注点。如果您的应用程序服务层中可用的所有用例都使用域模型在系统中进行更改，并且聚合根稍后将发生的任何事情作为域事件发布，您可以为任何事件实现处理程序并将它们保存在您需要的审核日志格式。