DDD - How to validate an entity is valid when said entity is a different domain which i dont have access to

Question

I am wondering how I would validate some actions in my domain when a parameter of an action needs to be validated, but that parameter's entity is actually in a different domain so I can't retrieve it.

Let's say I have the following situation:

// "Document" Domain
public class Document
{
    Guid Uuid {get;set;}
    Guid UserUuid {get;set;}
    // Other document properties..
}

// "User" Domain
public class User
{
   Guid Uuid {get;set;}
   UserType Type {get;set;}
   // Other user properties..
}

public enum UserType
{
   NormalUser = 0,
   Employee = 1
}

As you can see, these 2 classes are in 2 domains. In my situation, both of these are in the same service (DocumentService), but they are in different assemblies. Project.Domain.DomainA and Project.Domain.DomainB. They have no reference to eachother.

There are also classes like UserRepository and DocumentRepository which perform data actions. Furthermore, I use CQRS to issue commands. So, for example, creating a document through an api would be like this:

API -> CommandHandler -> Domain -> Persistence

Let's say I need to implement the following:

Allow employees to share a document by sending them to other employees. If the employee tries to share the document to a user who is a NormalUser, an error should occur.

The first part sounds easy enough. I would add a Share method to Document to implement the Sharing functionality. I pass the Uuid instead of the User, because the document domain has no knowledge of the domain where User is located.

void Share(Guid userUuid)
{
  // Share logic, events.. etc..
}

But now I need to validate that the user's type is Employee. Normally that would be easy enough: User.Type == UserType.Employee. But in this case, I have no access to the User type so I can't perform this test in my domain like this. So, the following isn't possible:

public void Share(User user)
{
    if (user.Type != UserType.Employee)
    {
        throw new Exception();
    }
}

I see a few options, but I would like to know what you guys think is best.

• Validate this logic in the commandhandler:

  var document = documentRepository.GetDocumentByUuid(uuid);
  var user = userRepository.GetUserByUuid(userUuid);
  if (user.Type != UserType.Employee)
  {
      throw new Exception();
  }
  
  document.Share(user.Uuid);
  

  • To me, this is a bad idea. If another commandhandler or any other place in the codebase would try to share a document, this validation would not take place. Furthermore, I believe this validation should take place in my domain.
• Validate this logic in a validator service of some kind:

  // New interface in the Document domain
  interface IDocumentSharingValidator
  {
      bool CanShareToUser(Guid userUuid);
  }
  
  // This is the Share method in the Document class
  void Share(Guid userUuid, IDocumentSharingValidator validator)
  {
      if(validator.CanShareToUser(userUuid))
      {
          // YAY!
      }
  }
  

  • This seems OK. But where would I place the implementation of IDocumentSharingValidator? It needs to talk to the data layer to retrieve the User, so I see 3 choices:
    • Put it in the Application layer and make it use the UserRepository to do validation.
      • To me, this is the best option right now. But it doesn't feel like good DDD for some reason? It is not limited to my Document domain anymore; it is just part of the application layer now.
    • Put it in the DocumentRepository (Which is in the Data layer) and make it talk to the User table (We use EF Core, so that would be dbContext.Users)
      • Ugly. We still talk to a User table in our Document Repository, so there is a bit of coupling.
    • Ok, so we put it in the UserRepository and make it talk to the User table.
      • Ugly because the UserRepository now uses an implements an interface from the Document domain.

Can you guys help me out? What would be a good idea? And how could I improve my DDD skills about this for the future? :)

Thanks!

Answer 1

The two classes may be isolated in different assemblies, and that's fine, but that's not what we mean by domain (domain is just the overall problem space that you're working on). So in that sense, this is all within the same domain.

Now, the fact that these are in different assemblies doesn't really matter (except in the organizational sense). What you have here are two different aggregates. Based on your code, conceptually, Document is an aggregate root, and it references a User, another aggregate root.

It looks like you're following Vaughn Vernon's approach where you only reference other aggregates by an ID, to demarcate aggregate boundaries. This approach relies on repositories to obtain the actual objects via the ID. You can do it in two ways - (1) the entities can maintain a dependency to a repository so that they can internally look up the object (essentially lazy loading), and (2) you can push some of the logic a level up, into services, and look up dependent entities ahead of time. Vernon recommends (2) as that way entities and aggregates don't have to depend on the repositories.

The "only reference other aggregates by ID" rule applies to class fields; the reason is to be able to load an aggregate as a complete, usable object, without having to simultaneously load the dependencies when you don't actually need them (and also to make it clear where the aggregate boundaries are). Having a method like void Share(User user) is, on the other hand, perfectly fine, because it doesn't force you to load the User object when you create/reconstitute an instance of the Document aggregate - you just can't call the method. In fact, such a method would signal to developers that they need to obtain a user object before they can call it, which is in line with the style (2) - ahead of time dependency lookup.

Side note: If you are referencing other entities that you have designated to be in the same aggregate, you don't reference them by an ID, but directly. This is what I mean when I say that this is a technique that demarcates aggregate boundaries in code. Direct reference - same aggregate, a reference by an ID - different aggregate.

So, ahead of time dependency lookup would look something like this (adapted from Vernon's guide, part 2, link below):

public class DocumentSharingService 
{
  public void ShareDocumentWithUser(Guid documentUuid,  Guid userUuid) 
  {
    Document doc = documentRepo.GetDocument(documentUuid);

    // you know a user is needed, so you obtain the user object as well
    User user = userRepo.GetUser(userUuid);  

    // You could place additional logic here, especially logic that 
    // doesn't have a clear home in either Document or User.

    doc.Share(user);   // Share can now validate the user
  } 

  // Other methods...
}

// then you call this service from your commandhandler 
// or any other place in code. 
// You either have to arrange things so that you can't 
// update the underlying system (or DB) except through such services
// (if you need to enforce the additional logic above), 
// OR keep the design simple and rely on developer discipline 

You can find the aforementioned 3-part guide by Vernon here.

On a final note, keep in mind that this is an approach to DDD and aggregate design, and not the one an true way to do DDD. It's much more important to understand the concepts and reasoning behind them than it is to religiously follow these rules.

Also, if your current design feels more like it's getting in the way instead of helping, don't be afraid to rethink your aggregates. We don't organize the code into aggregates because it's a "best practice", but because we want to get some benefits from doing that (e.g., low coupling through aggregate roots, high cohesion, consistency boundaries, usability improvements, etc.)

Answer 2

There are a couple of things here, some of it may not be related to DDD depending on interpretation.

If two domains are used in the same service those are by definition not different domains. There is no reason to separate two things that are used together or have to know each other in some form.

Can't help but notice that your "objects" are data-heavy. Domain objects should contain domain behavior, not data. These data-centric objects result in logic scattered all over the application, which is part of your current problems.

CQRS does not impact domain design. It is more of a persistence strategy that is sometimes pretty useful, in some circumstances. It should not be visible at all.

All in all it seems to me (and I obviously don't know all your requirements), that you are overthinking, over-patternizing this whole thing. Instead, what you should do is express clear intent in your design. If you believe (I think correctly), that Document.ShareWith(User) would best express your required functionality go with that. Always go with clear intent first. Worry about showing your architecture/DDD/CQRS prowess somewhere else.

Answer 3

Other answers suggest you might be better off with a single Bounded Context. To be honest that might be true. This answer is for situations where there are two (or more) separate Bounded Contexts.

You could create an EmployeeRepository in the Document context. This repository maps to the same underlying persistence mechanism as the UserRepository in the User context. In the Document context, I would not call this a UserRepository, because Users are not relevant here, only Employees are.

If you follow this approach, you have Employees available in the Document context and you can create a

public void Share(Employee employee)

method.

Note that Employees don't have to have all properties Users have in the User context, perhaps a Name and Id are enough. Also note that the EmployeeRepository should not have a Save method. Employee (User) related changes should be done in the User context.