Ggtcf

I've been working on a new document management project that uses DDD architecture. I'm new to DDD and event driven design, so it's been a learning experience.

My application is structured like this:

• MyProgram.Domain


• MyProgram.Infrastructure


• MyProgram.App


• MyProgram.WebApi

Domain has all of my domain logic, infrastructure is persistence, application is mostly commands and handlers, and the webapi is just the thing webapi.

Right now I'm working on implementing user authorization, and at the moment I've decided on using authorization handlers that will do permissions check before a command or query is executed. I think this gives me good flexibility perform complex resource-based authorization, since many of my permissions will depend on the current state of a certain entity.

So that is working out so far, I've implemented authorization in my application layer, leaving most of the user-specifics out of my domain model.

Now, the problem I'm trying to figure out is how to best include user information in my domain events, raised from my domain classes.

Example, I have a certain aggregate, let's say its document, and the document has a certain approval workflow. So when the document gets approved, I want to raise a domain event such as

public class DocumentApproved : IDomainEvent

 public DocumentApproved (Package package)
 
 DocumentId= document.Id;
 Timestamp = DateTime.Now;
 
 public Guid Id get; 
 public Guid UserId get; 
 public DateTime Timestamp get; 
 public Guid PackageId get; 

The system needs to be auditable, so I'm planning on using the domain events both as an audit trail as well as a mechanism to cause side effects or message other systems.

The Document entity might have a method that looks something like this:

 public void Approve()
 
 State = State.Approve(this);
 ApprovalRevision.Next();
 Events.Add(new DocumentApproved(this));
 

My Question

I'd like to include the UserId on just about every applicable domain event, but I can't think of how do to this without having to have the userId be a parameter for every relevant method on my domain entities, meaning they would only be a parameter for the sake of creating the domain events, since all authorization type activity will be happening in the application layer.

Is this a reasonable way to approach this, or maybe should I be trying to capture user activity a different way, such as my request pipeline, and keep those separate from domain events? That doesn't quite sound right to me. It really isn't such a problem to have the userId be a parameter for every method that might cause a domain event, but this seems like it would just be adding clutter to every domain entity signature.

For raising my domain events, I'm doing something similar to what is suggested here, where the entity has a DomainEvents collection, and they are published via MediatR right before the entity is saved.

The most pragmatic way of doing this would probably be to simply store the user's information (along with other session/request info) as event metadata (hopefully your event store supports that) and handle this concern outside the domain.

For instance, in one application I've written an event store implementation that can be configured with an EventMetadataProvider, which gets registered in the application's composition root and uses the current request context to append metadata such as the user's ID, remote IP address, etc.

Note that you could still enrich some domain events with the approver/creator/etc. where it matters the most for event consumers, but ideally not with a generic UserId concept.

 I think this gives me good flexibility perform complex resource-based authorization, since many of my permissions will depend on the current state of a certain entity.

That sounds like the authorization is an important part of the business rules and should be implemented in the domain layer. The fact that you have the need to enrich the domain events with user information is an indicator that the user should be part of the domain.

Without knowing the domain exactly I could imagine you have an invariant, something like: "A document can only be approved by the line manager of the author". You can not assert this invariant in the domain without the concept of users/roles.