기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

기타 고려 사항

지금까지 API Gateway 및 Windows 컨테이너를 사용하여 레거시 ASP.NET 웹 서비스를 현대화하는 방법에 대해 설명했습니다 AWS. 고려해야 할 몇 가지 다른 고려 사항은 다음과 같습니다.

다음 단원에서 각각에 대해 살펴 봅니다.

인증 및 권한 부여

최신 APIs 일반적으로 OAuth 2.0 및 OpenID Connect와 같은 토큰 기반(JSON 웹 토큰 또는 JWT) 인증 및 권한 부여 표준을 활용하는 반면, 레거시 ASP.NET 웹 서비스는 전통적으로 Windows Active Directory 도메인에 대한 기본 인증 또는 Windows 통합 인증에 의존했습니다. 모범 사례로, 이전 및 새로운 인증 및 권한 부여 접근 방식이 호환되지 않는 경우 웹 서비스를 현대화하기 전에 이러한 보안 메커니즘을 업그레이드하는 것이 좋습니다 AWS. 자격 증명을 매핑하거나 이전 시스템과 새 시스템 간에 보안 상태를 안전하게 전송하려고 시도하는 것은 큰 노력이 아닐 수 있지만 보안 취약성이 발생할 수 있습니다.

도메인 기반 설계

모놀리스를 개별 서비스로 나눌 때 DDD(도메인 기반 설계)는 시스템을 응집력 있는 비즈니스 도메인으로 모델링하는 데 자주 사용되는 모범 사례입니다. DDD는 구현을 진화하는 핵심 비즈니스 개념 모델에 연결하여 복잡한 요구 사항에 맞는 소프트웨어를 개발하는 접근 방식입니다. 그 전제는 프로젝트의 주요 초점을 핵심 도메인 및 도메인 로직에 두고, 비즈니스를 반영하는 모델을 기반으로 시스템 설계를 설계하는 것입니다. 기존 모놀리식 애플리케이션을 현대화할 때 DDD를 사용하는 경우 모놀리식의 기능 및 사용자 흐름에서 역방향으로 작업해야 합니다. DDD를 스트랭글러 패턴과 함께 사용하여 모놀리스를 깨고 스트랭글링할 서비스를 결정하는 프로세스를 안내할 수 있습니다. 따라서 도메인 기반 설계라는 용어가 사용됩니다.

중간 상태 및 대상 상태

몇 개 이상의 ASP.NET 웹 서비스를 현대화하는 경우 AWS먼저 모든 서비스가 현대화된 후 대상 상태 아키텍처를 정의하는 것이 좋습니다. 그러나 비즈니스 컨텍스트가 자주 변경되고 비즈니스 목표에 맞게 유지하려면 필요에 따라 시스템 대상 상태를 업데이트해야 하므로 대상 상태 아키텍처가 반드시 최종 상태 또는 최종 상태일 필요는 없습니다. 대상 상태를 정의한 경우 거기에서 역방향으로 작업하여 대상 상태 비전을 점진적으로 이행하는 중간 상태 아키텍처를 정의할 수 있습니다. 이러한 중간 상태 아키텍처는 호스트 트리의 주요 부분을 접하고 묶을 때 스트랭글러 무화과가 나무를 따라 이동하는 것으로 생각할 수 있습니다. 중간 상태 아키텍처는 대상 상태로의 진화를 촉진하기 위해 최종 상태 아키텍처의 일부가 아닌 임시 또는 중첩 구문을 도입하는 경우가 많습니다. SOAP 기반 ASP.NET 웹 서비스의 현대화는 예제를 제공합니다. Windows 기반 컨테이너는 새 REST API로 업그레이드할 수 있을 때까지 레거시 서비스에 의존하는 호출 시스템 간의 격차를 메우기 위해 일시적으로 도입됩니다.