기타 고려 사항

지금까지는 API Gateway 및 Windows 컨테이너를 사용하여 기존 ASP.NET 웹 서비스를 현대화하는 방법을 살펴보았습니다AWS. 고려해야 할 몇 가지 다른 고려 사항은 다음과 같습니다.

• 보안

• 리모델링 서비스 도메인

• 현대화해야 할 서비스가 많을 때 웹 서비스 업그레이드 순서 지정

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

인증 및 권한 부여

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

도메인 기반 설계

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

중간 상태 및 대상 상태

에서AWS 몇 개 이상의 ASP.NET 웹 서비스를 현대화하는 경우 모든 서비스를 현대화한 후에 대상 상태 아키텍처를 먼저 정의하는 것이 좋습니다. 그러나 대상 상태 아키텍처가 반드시 최종 상태이거나 최종 상태일 필요는 없습니다. 비즈니스 컨텍스트는 자주 변경되며 필요에 따라 시스템 대상 상태를 업데이트하여 비즈니스 목표에 맞게 조정해야 하기 때문입니다. 목표 상태를 정의했으면 거기에서 역방향으로 작업하여 목표 상태 비전을 점진적으로 충족하는 중간 상태 아키텍처를 정의할 수 있습니다. 이러한 중간 상태 건축물은 목 졸리는 무화과 덩굴이 숙주 나무의 주요 부분을 만나 삼킬 때 나무 위로 올라가는 과정이라고 생각할 수 있습니다. 중간 상태 아키텍처는 대상 상태로의 진화를 촉진하기 위해 최종 상태 아키텍처에 속하지 않는 임시 또는 중복 구조를 도입하는 경우가 많습니다. SOAP 기반 ASP.NET 웹 서비스의 현대화는 이에 대한 예를 제공합니다. Windows 기반 컨테이너는 새 REST API로 업그레이드될 때까지 기존 서비스에 의존하는 호출 시스템 간의 격차를 해소하기 위해 일시적으로 도입되었습니다.