Where does Anti-corruption Layer layer fit in layered architecture? Integrating third-party services

Question

I'm trying to learn domain-driven design, and in my app I'm implementing authentication. I'm using Firebase Authentication to perform authentication. All authentication related stuff is in a separate bounded context called Authentication.

stupid question alert, but will authentication be considered a bounded context?

From what I've read online, third-party stuff should be considered a separate bounded context, because they don't follow the language of the bounded context we are building. So instead we have to make an anti-corruption layer that converts the user model returned to from the sign up and sign in functions.

If this anti-corruption layer refers both the firebase stuff and my authentication models, if the anti-corruption layer is in my bounded context, that means my bounded context is going to be coupled to firebase auth. So instead, should I keep the Anti-corruption layer separate and have the authentication bounded context refer to it instead?

Will it be something like this?

auth_bounded_context
|--application
   |--authentication_app_service
|--domain
   |--authentication_service

auth_firebase_anti_corruption_layer
|--authentication_adapter
|--firebase_to_authentication_User_Mapper

and then should the calls be like this?:

authentication_app_service.signIn(email, password)
-> authentication_service(email, password)
-> authentication_adapter(email, password) 

which returns the user model mapped from the firebase user model to my authentication BC user model.

And also, I want to know if my understanding of some things are correct.

1. Whatever is in domain layer should not be coupled to anything outside the domain, and if there is something from the outside that the domain wants to use, it must an interface in the domain and implemented in the infrastructure layer. So does that mean the infrastructure layer can be coupled with third party libraries or other bounded contexts? And what if information from repositories is needed in between a domain service?

2. Can repository be used in domain services, since its part of the domain? From what I've heard, repositories being used in domain is bad practice because it becomes harder to test stuff. So would this rule apply to all third party services, and not just repositories?

Starting out with no guidance is soo confusing :) I'm aware that I would have said a lot of dumb things, so please correct me.

And if anybody can provide me with resources to learn to implement domain driven design practically, please do.

Thanks in advance!

Answer 1

Spoiler alert, I'm not a DDD expert.

It sounds like you're getting the hang of DDD, but I think where you might be having issues is where theoretical DDD meets real-world challenges. (And I don't mean that as disrespect to DDD). In my world view, DDD is a great candidate for tackling non-trivial business problems, but, authentication is bit of a special world of it's own, so you're trying to push a square peg into a round hole.

The thing about authentication is that you aren't just exchanging data, you're exchanging sensitive data in an environment where different levels of trust exist, and where keeping the system secure relies on stuff working at different levels and tiers.

These days, you shouldn't be writing your own security related code, it's better to use solutions, systems, standards (etc) that are industry proven. Concepts like OpenID Connect come to mind.

In such a world, all you need to figure out is what auth related platform/technology/solution you're going to use and figure out how to do that elegantly in your solution. The Anti-C layer pattern may or may not be a good approach in that case.