4

I'm tying to use Domain Driven Design in one of my applications and have some question about user authentication.

I have an aggregate root called User which has Value Objects like UserCredentials, Password, ActivationToken, etc. I also have few domain services for managing users. For example UserRegistration service looks like this:

public interface IUserRegistrationService
{
    IEnumerable<string> Register(NewUserRequest request);
}

It checks business rules that are assigned to user registration process and persist user in the database.

Now I want to authenticate user, so I've created UserAuthentication domain service:

public interface UserAuthenticationService
{
    IEnumerable<string> Authenticate(AuthRequest request);
}

It takes user from the repository, checks business rules, updates and persists user data changes like LastLoginDate.

But I have some doubts if authentication process belongs to domain itself or it should belong to application service, as for my domain it doesn't matter how user is authenticated. But on the other hand authentication rules, that are checked inside this service, belong to my domain rules, so they're integral part of my domain.

So where do you put authentication in your DDD based appllications and what is your solution to this issue?

Mad Max
  • 186
  • 2
  • 11

3 Answers3

4

1.Generally, authentication and authorization are su-domains in an application. You'd better build an abstraction in application layer/core domain to isolate them.

public interface OrderingService// application layer
{
    void PlaceOder(Order order) {
          //delegate to identity subdomain to validate user request
          UserAuthenticationService.Authenticate(ExtractFrom(order));

          //delegate to booking core domain to handle core business 
          BookingService.placeOrder(order);
    }
}

2.In Identity subdomain, the authentication algorithm could be placed in infrastructure layer:

public class OathUserAuthenticationService:UserAuthenticationService //infrastructure layer
{
    IEnumerable<string> Authenticate(AuthRequest request) {
         ......
    }
}

There are excellent discussion and examples in Implementing Domain Driven Design. The author seperate authentication to an identity subdomain.

Yugang Zhou
  • 7,123
  • 6
  • 32
  • 60
1

Following answer is highly depends on my assumptions about your task and environment, so do not beleive me blindly.

I think authentication is a business process. It highly coupled with concepts of User, Registration, UserStatus etc.

If you ask me how to call this business process with the single word, I'd choose UserPolicy. Look at UserPolicy as an aggregate root. It's boundaries includes such entities as: User, RegistrationService, AuthenticationService, UserRepository. All of them must remain consistent. It is easy to achieve, because every action with them is going through their root entity:

IUserPolicy up = container.Resolve<IUserPolicy>();

up.RegisterUser(newUserRequest);

up.AuthUser(authRequest);
astef
  • 8,575
  • 4
  • 56
  • 95
-2

In Domain-Driven Design (DDD), the authentication layer is not typically considered part of the core domain. Authentication is usually considered a cross-cutting concern or an infrastructure concern that deals with security and user identity. Therefore, it is commonly placed in the infrastructure layer of the DDD architecture.

The infrastructure layer in DDD is responsible for handling technical concerns such as database access, external services integration, messaging, security, and authentication. It provides the infrastructure necessary to support the core domain and enable its execution.

Here's a high-level overview of how the authentication layer can be structured within the DDD architecture:

Core Domain Layer: This layer contains the business logic and entities that represent the core domain of your application. It focuses on solving the specific business problems and encapsulates the domain-specific concepts and rules.

Application Layer: The application layer sits on top of the core domain layer and acts as an orchestrator. It coordinates the interactions between the user interface, domain layer, and infrastructure layer. It defines application services that encapsulate the use cases of the system and often interfaces with the authentication layer for user authentication and authorization.

Infrastructure Layer: This layer is responsible for providing technical components and services. It includes implementations for data persistence, external service integrations, messaging systems, and security/authentication mechanisms. The authentication layer, including components like user repositories, authentication services, and security middleware, resides within this layer.

By placing the authentication layer in the infrastructure layer, you can keep the core domain focused on the business logic while allowing the infrastructure layer to handle authentication-related concerns. This separation of concerns promotes a clear and modular architecture that adheres to the principles of DDD.

M.Ali El-Sayed
  • 1,608
  • 20
  • 23