UserCase가 많은데... 이유?

네 강의자 한정헌입니다. 말씀하신 바대로 헥사고널 아키텍처에서도 예를 들면 CUD단위로 하나의 유스케이스 인터페이스로 묶고 이를 구현하는 입력포트도 하나의 클래스로 작성할 수 있습니다. 처음에 간단했던 cud야 괜찮겠지만 비지니스가 점점 복잡해지면 유지보수가 거듭되면서 이 클래스가 점점 비대해질 가능성이 있습니다. 그래서 저는 기능 단위로 유스케이스와 입력포트를 분리하는 방법을 선호합니다. 유스케이스 단위로 클래스 생성하는 방식에 대해서는 클린코드의 저자 로버트 c 마틴이 ‘ 소리치는 아키텍처(코드의 명칭을 통해 그 의도롤 소리치게 하자.)’라고도 언급하며 강조를 하기도 했습니다. 왜냐면 이렇게 했을 경우 코드명으로 그 의도를 바로 식별할 수 있기 때문이죠. 즉 클래스 명만 보고 어떠한 유스케이스인지 쉽게 인지 가능하기 때문에 테스트 및 유지보수성 높아 질수 있음을 강조했다고 생각합니다. 감사합니다.

음성 부분이 너무 깨지는데...

강의자입니다. 죄송합니다. 제가 음질을 개선 시킨다고 한것이 더 망쳐 놨네요. 주변 잡음이 들린다 하셔서 잡음을 잡는 다는 것이 목소리가 너무 울리게 했네요. 우선 목소리가 울리지 않고 잡음이 줄이는 방식으로 급히 조치를 했습니다. 좀더 보완하고 개선하도록 노력하겠습니다.

CQRS 질문 드립니다.

네 CQRS의 개념과 장점에 대해 정리해 보면 다음과 같습니다. 관심 사항 분리 : CQRS는 데이터를 수정하는 작업(명령)과 데이터를 읽는 작업(쿼리) 간의 명확한 분리를 촉진합니다. 이러한 분리는 각 구성 요소를 특정 책임에 집중함으로써 애플리케이션의 설계 및 유지 관리를 단순화합니다. 최적화 : 명령과 쿼리를 분리하여 각 측면을 특정 요구 사항에 따라 독립적으로 최적화할 수 있습니다. 예를 들어, 명령 측은 쓰기가 많은 워크로드에 최적화되어 빠르고 일관된 데이터 업데이트를 보장할 수 있으며, 쿼리 측은 읽기가 많은 워크로드에 최적화되어 효율적인 데이터 검색 및 표시가 가능합니다. 확장성 : CQRS를 사용하면 해당 작업 부하에 따라 명령 및 쿼리 구성 요소를 독립적으로 확장할 수 있습니다. 이러한 유연성을 통해 리소스 활용도를 높이고 성능을 조정하여 다양한 수준의 트래픽과 처리 요구 사항을 처리할 수 있습니다. 복잡한 도메인 처리 : 데이터 모델이나 비즈니스 로직이 복잡한 복잡한 도메인에서 CQRS는 보다 표현력이 뛰어나고 유지 관리가 쉬운 솔루션을 제공할 수 있습니다. 이를 통해 개발자는 도메인의 특정 요구 사항에 맞게 명령 및 쿼리 모델을 맞춤화하여 두 가지 책임을 단일 모델에 맞추려고 할 때 발생할 수 있는 타협을 피할 수 있습니다. 이벤트 소싱 통합 : CQRS는 또 다른 아키텍처 패턴인 이벤트 소싱과 함께 사용되는 경우가 많습니다. 이벤트 소싱에는 애플리케이션 상태에 대한 모든 변경 사항을 일련의 불변 이벤트로 캡처하는 작업이 포함됩니다. CQRS는 이벤트를 트리거하는 명령과 이를 사용하는 쿼리를 명확하게 구분하고 이벤트 기반 아키텍처를 촉진하며 변경 사항을 감사하고 재생하기 위한 강력한 메커니즘을 제공함으로써 이벤트 소싱을 보완합니다. 유연성 : CQRS는 애플리케이션의 다양한 부분에 적합한 데이터 저장 메커니즘과 쿼리 모델을 선택할 수 있는 유연성을 제공합니다. 예를 들어, 명령 측에서는 트랜잭션에 최적화된 기존 관계형 데이터베이스를 사용할 수 있고, 쿼리 측에서는 읽기 작업이 많은 워크로드에 최적화된 NoSQL 데이터베이스 또는 복잡한 쿼리를 위한 특수 인덱싱 솔루션을 사용할 수 있습니다. 질문하신 내용을 개념에 대비해서 살펴보면 1,4번에 해당되는 것처럼 도메인 모델이 복잡해지는 것을 피하기 위해 단순 질의를 분리하면 유지보수성과 유연성이 높아 질 수 있습니다. 커맨드 와 질의 에 대한 서버분리를 질문하셨는데 2,3의 최적화와 확장성을 위해서는 각각의 서버(서비스)를 분리하는 것이 효과적이라고 생각합니다. 그리고 로직의 검증을 위한 조회나, 로직상 필요한 조회는 명령의 부분이라고 생각합니다. 감사합니다.

강의 음성 및 영상

불편을 드려 죄송합니다 😔 제가 음성이 불명확하고 잘린부분을 살펴 금주중으로 보완하는 강의를 업로드 하도록 하겠습니다.

모듈형 모노리스의 컨테이너화

좀더 상세히 말씀드리면 마이크로서비스가 아닌 모노리스 애플리케이션을 컨테이너화하고 이를 Kubernetes에 배포하는 것은 마이크로서비스로 변환하여 배포하는 장점보다는 못미치지만 그 정도로써의 충분한 이점( 확장성, 배포 및 탄력성 측면에서) 이점을 제공합니다. 장점은 다음과 같습니다. 확장성 : Kubernetes를 사용하면 수요에 따라 컨테이너 인스턴스를 추가하거나 제거하여 애플리케이션을 수평으로 확장할 수 있습니다. Kubernetes에 컨테이너화되고 배포된 모놀리식 애플리케이션을 사용하면 이러한 확장성의 이점을 누릴 수 있습니다. 내부 모듈이 독립적으로 확장되도록 설계된 경우 모놀리스의 개별 구성 요소(모듈)을 쉽게 분리하여 확장하거나 더 많은 컨테이너 인스턴스를 추가하여 전체 모놀리스의 크기를 조정할 수 있습니다. 배포 : Kubernetes는 여러 노드 또는 클러스터에 애플리케이션을 배포하는 기능을 제공합니다. Kubernetes에 모놀리식 애플리케이션을 배포하면 여러 노드에 분산하여 내결함성과 가용성을 향상시킬 수 있습니다. 또한 Kubernetes는 로드 밸런싱 및 서비스 검색과 같은 기능을 제공하여 배포작업을 더욱 향상시킬 수 있습니다. 탄력성 : Kubernetes는 HPA(Horizontal Pod Autoscaler)와 같은 기능을 통해 수요에 따라 컨테이너에 할당된 리소스를 자동으로 조정할 수 있습니다. 즉, 모놀리식 애플리케이션은 트래픽이나 리소스 사용량의 변화에 ​​따라 동적으로 확장하거나 축소할 수 있습니다. 탄력성은 애플리케이션이 성능과 비용 효율성을 유지하면서 리소스를 효율적으로 활용할 수 있도록 보장합니다. 그렇지만 염두에 두어야 할 고려 사항도 있습니다. 복잡성 : Kubernetes에서 모놀리식 애플리케이션을 배포하고 관리하면 기존 모놀리식 서버 아키텍처에 비해 더 많은 복잡성이 발생합니다. 파드, 디플로이, 서비스와 같은 Kubernetes 리소스를 구성하고 관리해야 합니다. 이러한 복잡성으로 인해 학습 곡선과 운영 오버헤드가 증가할 수 있습니다. 리소스 오버헤드 : 컨테이너화 및 Kubernetes에는 약간의 리소스 오버헤드가 수반됩니다. Kubernetes는 컨테이너 관리를 위한 강력한 기능을 제공하지만 효과적으로 작동하려면 리소스도 필요합니다. 애플리케이션의 크기와 복잡성이 단순한 경우에는 Kubernetes로 인한 오버헤드가 정당화되지 않을 수 있습니다. 마이그레이션 노력 : 모놀리식 애플리케이션을 컨테이너화하고 이를 Kubernetes에 배포하려면 특히 애플리케이션이 컨테이너화를 염두에 두고 설계되지 않은 경우 상당한 노력이 필요할 수 있습니다. 컨테이너 친화적으로 만들기 위해 애플리케이션의 일부를 리팩터링해야 할 수도 있는데, 이는 시간이 많이 걸리고 어려울 수 있습니다. 성능 : Kubernetes는 확장성과 탄력성을 제공하지만 특히 분산 환경용으로 설계되지 않은 모놀리식 애플리케이션의 경우 성능에 영향을 미칠 수 있습니다. 구성 요소 간 통신 오버헤드, 네트워크 대기 시간 증가, 리소스 경합 등이 성능에 영향을 미칠 수 있는 요소입니다. 결론적으로, Kubernetes에 모놀리식 애플리케이션을 배포하면 확장성, 배포 및 탄력성 측면에서 이점을 제공할 수 있지만 이점이 관련된 복잡성 및 고려 사항보다 중요한지 신중하게 평가하는 것이 중요합니다. 특정 사용 사례, 요구 사항 및 조직 기능에 따라 Kubernetes가 아키텍처에 가장 적합한 선택일 수도 있고 아닐 수도 있습니다. 결정을 내리기 전에 장단점을 고려하고 대체 접근 방식을 고려하는 것이 중요합니다.