本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
其它考虑因素
到目前为止，我们已经讨论了使用 API Gateway 和 Windows 容器对传统 ASP.NET Web 服务进行现代化改造AWS。以下是需要考虑的其他注意事项：
-
安全性
-
重塑服务域
-
当有许多服务需要现代化时，对 Web 服务升级进行排序
以下各节将讨论这些内容。
身份验证和授权
现代 API 通常使用基于令牌（JSON Web 令牌或 JWT）的身份验证和授权标准，例如 OAuth 2.0 和 OpenID Connect，而传统的 ASP.NET Web 服务传统上依赖于 Windows Active Directory 域的基本身份验证或 Windows 集成身份验证。最佳做法是，如果新旧的身份验证和授权方法不兼容，我们建议您在对 Web 服务进行现代化改造之前，先升级这些安全机制AWS。尝试映射身份或尝试在新旧系统之间安全传输安全状态可能不是一项重大工作，但可能会引入安全漏洞。
领域驱动设计
在将整体架构分解为单个服务时，域驱动设计 (DDD) 是一种最佳实践，通常用于将系统建模为紧密的业务领域。DDD 是一种开发满足复杂需求的软件的方法，方法是将实现与不断演变的核心业务概念模型联系起来。其前提是将项目的主要重点放在核心领域和领域逻辑上，并将系统设计建立在反映业务的模型基础上。如果您在对现有单体应用程序进行现代化改造时使用 DDD，则需要从整体架构的功能和用户流程向后推进。你可以将 DDD 与 strangler 模式结合使用，指导打破整体结构和确定要扼杀哪些服务的过程，因此被称为领域驱动设计。
临时状态和目标州
当您要对多个 ASP.NET Web 服务进行AWS现代化改造时，最好先定义所有服务现代化后的目标状态架构。但是，目标状态架构不一定是最终状态或最终状态，因为业务环境经常变化，系统目标状态应根据需要进行更新以与业务目标保持一致。定义目标状态后，可以从那里向后移动，定义逐步实现目标状态愿景的临时状态架构。你可以把这些临时状态架构看作是扼杀者无花果藤在遇到并吞没宿主树的大部分时在树上前进。临时状态架构通常会引入不属于终端状态架构一部分的临时或重叠结构，以促进向目标状态的演变。基于 SOAP 的 ASP.NET Web 服务的现代化就是一个例子：暂时引入了基于 Windows 的容器，以弥合依赖传统服务的调用系统之间的差距，直到它们可以升级到新的 REST API。
