问题描述
我正在尝试学习领域驱动设计，并在我的应用中实现身份验证。我正在使用 Firebase 身份验证来执行身份验证。所有与身份验证相关的内容都在一个单独的有界上下文中，称为身份验证。
愚蠢的问题警报，但身份验证会被视为有界上下文吗？
从我在网上阅读的内容来看，第三方的东西应该被视为一个单独的有界上下文，因为它们不遵循我们正在构建的有界上下文的语言。因此，我们必须创建一个反腐败层，用于转换从注册和登录函数返回的用户模型。
如果这个反腐败层同时引用了 firebase 的东西和我的身份验证模型，如果反腐败层在我的有界上下文中，那意味着我的有界上下文将与 firebase auth 耦合。那么，我应该将反腐败层分开，并让身份验证有界上下文引用它吗？
会是这样吗？
auth_bounded_context
|--application
|--authentication_app_service
|--domain
|--authentication_service
auth_firebase_anti_corruption_layer
|--authentication_adapter
|--firebase_to_authentication_User_Mapper
然后调用应该是这样的吗？：
authentication_app_service.signIn(email,password)
-> authentication_service(email,password)
-> authentication_adapter(email,password)
返回从 firebase 用户模型映射到我的身份验证 BC 用户模型的用户模型。
还有，我想知道我对某些事情的理解是否正确。
-
域层中的任何东西都不应该耦合到域外的任何东西，如果域想要使用来自外部的东西，它必须是域中的接口并在基础设施层中实现。那么这是否意味着基础设施层可以与第三方库或其他有界上下文耦合？ 如果域服务之间需要来自存储库的信息怎么办？
-
存储库是否可以用于域服务，因为它是域的一部分？据我所知，在域中使用存储库是不好的做法，因为测试内容变得更加困难。那么这条规则是否适用于所有第三方服务，而不仅仅是存储库？
在没有指导的情况下开始真是令人困惑:) 我知道我会说很多愚蠢的话，所以请纠正我。
如果有人可以为我提供资源来学习实践领域驱动设计，请这样做。
提前致谢！
解决方法
剧透警告，我不是 DDD 专家。
听起来您已经掌握了 DDD 的窍门，但我认为您可能会遇到问题的地方是理论上的 DDD 遇到了现实世界的挑战。 （我的意思并不是对 DDD 的不尊重）。在我看来，DDD 是解决重要业务问题的绝佳候选者，但是，身份验证本身就是一个特殊的世界，因此您正试图将方钉推入圆孔中。
关于身份验证的问题在于，您不仅要交换数据，还要在存在不同信任级别的环境中交换敏感数据，在这种环境中，保持系统安全依赖于在不同级别和层级工作的东西。
如今，您不应该编写自己的安全相关代码，最好使用经过行业验证的解决方案、系统、标准（等）。想到 OpenID Connect 等概念。
在这样的世界中，您只需要弄清楚您将使用什么与身份验证相关的平台/技术/解决方案，并弄清楚如何在您的解决方案中优雅地做到这一点。在这种情况下，Anti-C 层图案可能是也可能不是一个好方法。