Domain Driven Design implement aggregates

Question

I have read about creating and responsibilities of aggregates and I have doubts how to correctly implement them. Assume that we have context within there are 2 entities. One is a Company and the second one is a User. Business rules are in the Company entity that means this should become aggregate root. To the Company we can assign ony 3 users and we can not assign User when Comapny has status "blocked". User has also possibility to login using emial and password. With that in mind every action on User entity should bo invoked thru the Aggregate root and User should not have it's own Repository. How to make login action on User when we can not do it directly without Company root? We can not call User out of the aggregate. How to find User with provided email and password? Fetching all Aggregates and iterating over their Users is inefficient and I think it's not a good idea. Thank you for help.

Answer 1

Authentication usually isn't part of a domain (in 99% of all use cases), just part of the infrastructure.

As such Users shouldn't ever appear within a bounded context. In the real business world, there are no users neither, only People, Persons, Employees, Managers or Contacts etc.

So for logging concerns you have our users with username + password which serve as authentication. These users have an id (numerical, string or guid).

Your Employee or Persons entity/aggregate (or what ever you named it depends on your domain, the exact term depends from company to company - the ubiquitous language) then only contains the data which belongs to the person (but not identificaton related information).

You can then connect employees to users (either by having the employee id be the id of the users used for login, an extra field or via a 1:1 or 1:n lookup table.

This way you can easily delete a user (the login) without deleting the Employee entity, because in real world scenarios you can't easily just delete business data (i.e. imagine deleting a user removes the recipient on every invoice or CRM data, no one would ever know this person worked there in the past).

Answer 2

I think that user should belong to another BC (that manages authentication and authorization). In your Company BC, you have to get the user from the authentication and authorization BC. You have to integrate both BCs with a context mapping pattern, where authentication and authorization BC is upstream, and Company BC is downstream.