How does your domain know your user?

Almost every business application needs to answer a question that sounds simple: who is the current user? But “user” isn’t one thing. Authorization needs to know what you’re allowed to do. Business rules need to know who you are. Audit trails need to know who did this. These are three different questions that should not be mixed into a single “user” object. So it helps to split the concept into two abstractions. Identity — who are you? public interface IIdentity; It might be a registered user: public sealed record UserIdentity(UserId Id, PersonName Name, Email Email) : IIdentity; the system itself — a background job, or a handler reacting to an event from another bounded context: public sealed record SystemIdentity : IIdentity; or anonymous: public sealed record AnonymousIdentity : IIdentity; Principal — what are you allowed to do? public interface IPrincipal { public bool HasRole(Role role); public bool HasPermission(Permission permission); } A registered user has roles and permissions granted within a company: public sealed record UserPrincipal(CompanyId CompanyId, IReadOnlySet<Role> Roles, IReadOnlySet<Permission> Permissions) : IPrincipal { public bool HasRole(Role role) => Roles.Contains(role); public bool HasPermission(Permission permission) => Permissions.Contains(permission); } The system can do anything: public sealed record SystemPrincipal : IPrincipal { public bool HasRole(Role role) => true; public bool HasPermission(Permission permission) => true; } and an anonymous caller can do nothing: public sealed record AnonymousPrincipal : IPrincipal { public bool HasRole(Role role) => false; public bool HasPermission(Permission permission) => false; } This is a simple model, but it’s a powerful starting point for…

Continue reading →