vendredi 22 juin 2018

DDD How to design services/aggregate roots involving related entities

I'm building an invitation system in which admins can only invite

  • users that are not already invited
  • users that are not already in the system (=already a member)

This flow involves two entities Invitation and User.

  • Deleting a user should not delete invitations he has sent
  • Updating the user's FirstName should not update all his invitations

This seems to indicate that Invitations and User should be added to two separated aggregates.

Then the only way to implement the logic described above is to use a domain service like IInvitationService. Am I right?

This interface could come with two methods:

public interface IInvitationService
{
    Task<Result> Create(Invitation invitation, CancellationToken token);
    Task<Result> Delete(Invitation invitation, CancellationToken token);
}

Finally, if I go for the service approach, I will have two possible "ways" to create invitations.

IInvitationRepository.Create() 
IInvitationService.Create()

Don't you think it is confusing?

Aucun commentaire:

Enregistrer un commentaire