Authentication and Authorization in DDD

A common scenario in an application is deal with authentication and authorization.
As I’m a great enthusiast of Domain-Driven Design, I wonder what are the best approaches to use authentication/authorization in DDD.
In the following lines I show two approaches based on an imaginary use case.

I am eager to hear your comments and suggestions.


Concepts that would be good to know:

Use Case example

Imagine we want to develop the next blogging platform.

We define the Ubiquitous Language in the context of the next blogging platform as below:

  • Author: existing user in the next blogging platform. It is Entity with unique identifier of authorId;
  • Blog: specific area of blogging platform containing posts. It is Entity with unique identifier of blogId;
  • Collaborator: Author who can create the posts to the given blog;
  • Authentication: process to identify the Author.
  • Authorization: process to check if the Author is Collaborator in the given Blog.

The use case that we have to develop is create a post in a blog where any collaborator of the blog can creates posts.
In order to compare both solutions, the use case can be executed from Web, REST and Console.

Note: the sample code has been simplified (dependencies, getters) in order to focus on important concepts.

Version 1: Authentication/Authorization outside Application Services

Once the request reaches the ApplicationService it is executed without check any authentication or authorization.



From controller (or from some hook of the framework), before the use case is executed, it checks if current user is authenticated and also if he is a collaborator of the blog.

In order to checks these things, we use DomainServices in the controller:


It uses header Authorization to get a token. It checks that this token belong to a user and also that this user is a collaborator in the blog.

In order to checks these things, we use DomainServices in the controller:


It executes the use case without checks authentication/authorization. userId comes from command line as parameter.

Sum up

  • Authentication/Authorization is checked outside from ApplicationService in the Controller (or in a hook in the framework).
  • Authentication/Authorization must be executed before ApplicationService use case.
  • Depending on entry point of the application an authentication service is uses. In the example OAuthService, SessionService.

Version 2: Authentication/Authorization within Application Services

Following Vernon’s example in his book IDDD and CollaboratorService, we can use the language inside the use case where authentication/authorization is executed implicitly.


It uses a DomainService named CollaboratorService that checks authentication and authorization behind the scenes. CollaboratorService returns Author ValueObject and its implementation may reach another bounded context.


Controller doesn’t need the check authentication/authorization. However to create the use case request and pass authorId parameter a common scenario is to read the userId from session. The rest of params comes from http request.
Then the implementation of CollaboratorService works directly with the userId value.


It uses http header Authorization to get the token of the user. When the entry point to the application is REST, the authentication mechanism could be OAuth, JWT… then the implementation CollaboratorService should works with that token.


authorId param comes from command line, so if the given author-id belongs to blog then no exceptions will be thrown:

The implementation of CollaboratorService could be the same as we use in Web or a specific implementation.

Sum up

  • All checks of authentication/authorization are within the ApplicationService implicitly used in CollaboratorService.
  • The input parameter in authorId in AddPostService is somehow polymorphic, due accepts tokens from REST or direct id value from Web. Maybe this is the key that allow us to put authentication/authorization within ApplicationService.
  • CollaboratorService needs several implementation depending on authentication mechanism.


  • 2016–01–08: added Ubiquitous Language description. Thanks to @robegrei

Software Engineer with true passion for creating clean, functional and well-designed code.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store