Cuándo actualizar los campos de auditoría? DDD

Question

que tiene un objeto de la reunión:

Meeting{id, name, time, CreatedBy, UpdatedBy}

y una reunión

MeetingAssignee{id, MeetingID, EmployeeId, CreatedBy, UpdatedBy)

, como root agregado, tiene una AssignEmployee método.

Estaba a punto de pasar al usuario actual al objeto Reunión al llamar a AssignEmployee, para que pueda actualizar sus campos de auditoría en consecuencia.

Pero esto no parece correcto, ¿verdad? Obviamente, puedo mantener los campos de auditoría públicos y cambiarlos más tarde, ¿quizás a nivel de servicio?

¿Cuál es el método preferido por todos los demás para actualizar estos campos?

Tenga en cuenta: No estamos utilizando Nhibernate, sino un ORM personalizado que no tiene nada automático en su lugar.

Gracias.

Answer 1

La auditoría y el registro son divertidos, ya que generalmente se necesitan en cualquier lugar de la aplicación y son ambos requisitos (el registro es obligatorio para los OP).

sin saber mucho de su modelo, y dado que la auditoría debe ser un requisito, me paso el usuario actual a AssignEmployee y en lugar de tener una línea de ahí que dice AuditBlahBlahBlah, me gustaría añadir un evento (tal vez MeetingUpdated o AssigneeAdded .. . encontrarás un buen nombre) y ese evento se envía a la clase que realiza la auditoría. De esta manera, la clase Meeting no tiene ni idea de auditar y despachar eventos comerciales para fines de auditoría (que, en mi opinión, es muy DDDish).

Me pregunto qué otras personas podrían decir (con suerte, puedo aprender algo nuevo!)

Answer 2

Usted podría hacer la llamada al servicio de auditoría de la capa de servicio cuando la persistencia o la actualización de las entidades, con el servicio de auditoría haber sido inyectado en cualquier servicio que requiera la funcionalidad de auditoría, y persistir las entidades recién creadas lo más rápido posible.

Veo cómo podría ser difícil determinar cómo y cuándo realizar una auditoría, especialmente si sus entidades van a existir como entidades utilizables en el sistema en algún momento antes de persistir. Incluso si existen por algún tiempo antes de persistir, tal vez podría crear datos de auditoría en memoria, que contengan los detalles de su creación y luego persistir cuando las entidades finalmente persisten. ¿O tienen los datos creados por, creados en, modificados, modificados, etc. como campos privados en la entidad y los escriben en un registro de auditoría cuando la entidad persiste?

Me interesaría saber cuáles serían las compensaciones.

Answer 3

Considere el uso de eventos de dominio.

Todo lo que sea interesante en su modelo de dominio debe provocar un evento que grite en voz alta lo que acaba de suceder. Desde afuera, simplemente conecte el controlador de registro que los vuelca en db o en otro lugar.

De esta manera, no necesita desordenar su dominio con algún tipo de IAuditService.

Mejor aún, el modelo de dominio puede usar eventos como una forma de comunicarse dentro de sí mismo.
Para mostrar por qué es una buena idea, visualice que estamos describiendo el modelo de dominio de la mañana, el amanecer y las flores.

¿Es responsabilidad del sol decir todas las flores que deben abrir? Realmente no. El sol solo necesita brillar con fuerza (para plantear un evento), la luz debe aterrizar (debe haber algún tipo de infraestructura que posibilite los eventos) y las flores deben reaccionar ellas mismas al recibir luz (otros modelos de dominio deben manejar eventos).

Otra analogía: es responsabilidad del conductor ver cuál es el color de los semáforos.