게시글
질문&답변
2024.04.27
UserCase가 많은데... 이유?
네 강의자 한정헌입니다. 말씀하신 바대로 헥사고널 아키텍처에서도 예를 들면 CUD단위로 하나의 유스케이스 인터페이스로 묶고 이를 구현하는 입력포트도 하나의 클래스로 작성할 수 있습니다. 처음에 간단했던 cud야 괜찮겠지만 비지니스가 점점 복잡해지면 유지보수가 거듭되면서 이 클래스가 점점 비대해질 가능성이 있습니다. 그래서 저는 기능 단위로 유스케이스와 입력포트를 분리하는 방법을 선호합니다. 유스케이스 단위로 클래스 생성하는 방식에 대해서는 클린코드의 저자 로버트 c 마틴이 ‘ 소리치는 아키텍처(코드의 명칭을 통해 그 의도롤 소리치게 하자.)’라고도 언급하며 강조를 하기도 했습니다. 왜냐면 이렇게 했을 경우 코드명으로 그 의도를 바로 식별할 수 있기 때문이죠. 즉 클래스 명만 보고 어떠한 유스케이스인지 쉽게 인지 가능하기 때문에 테스트 및 유지보수성 높아 질수 있음을 강조했다고 생각합니다. 감사합니다.
- 0
- 1
- 77
질문&답변
2024.04.07
음성 부분이 너무 깨지는데...
강의자입니다. 죄송합니다. 제가 음질을 개선 시킨다고 한것이 더 망쳐 놨네요. 주변 잡음이 들린다 하셔서 잡음을 잡는 다는 것이 목소리가 너무 울리게 했네요. 우선 목소리가 울리지 않고 잡음이 줄이는 방식으로 급히 조치를 했습니다. 좀더 보완하고 개선하도록 노력하겠습니다.
- 0
- 1
- 102
질문&답변
2024.03.31
CQRS 질문 드립니다.
네 CQRS의 개념과 장점에 대해 정리해 보면 다음과 같습니다. 관심 사항 분리 : CQRS는 데이터를 수정하는 작업(명령)과 데이터를 읽는 작업(쿼리) 간의 명확한 분리를 촉진합니다. 이러한 분리는 각 구성 요소를 특정 책임에 집중함으로써 애플리케이션의 설계 및 유지 관리를 단순화합니다. 최적화 : 명령과 쿼리를 분리하여 각 측면을 특정 요구 사항에 따라 독립적으로 최적화할 수 있습니다. 예를 들어, 명령 측은 쓰기가 많은 워크로드에 최적화되어 빠르고 일관된 데이터 업데이트를 보장할 수 있으며, 쿼리 측은 읽기가 많은 워크로드에 최적화되어 효율적인 데이터 검색 및 표시가 가능합니다. 확장성 : CQRS를 사용하면 해당 작업 부하에 따라 명령 및 쿼리 구성 요소를 독립적으로 확장할 수 있습니다. 이러한 유연성을 통해 리소스 활용도를 높이고 성능을 조정하여 다양한 수준의 트래픽과 처리 요구 사항을 처리할 수 있습니다. 복잡한 도메인 처리 : 데이터 모델이나 비즈니스 로직이 복잡한 복잡한 도메인에서 CQRS는 보다 표현력이 뛰어나고 유지 관리가 쉬운 솔루션을 제공할 수 있습니다. 이를 통해 개발자는 도메인의 특정 요구 사항에 맞게 명령 및 쿼리 모델을 맞춤화하여 두 가지 책임을 단일 모델에 맞추려고 할 때 발생할 수 있는 타협을 피할 수 있습니다. 이벤트 소싱 통합 : CQRS는 또 다른 아키텍처 패턴인 이벤트 소싱과 함께 사용되는 경우가 많습니다. 이벤트 소싱에는 애플리케이션 상태에 대한 모든 변경 사항을 일련의 불변 이벤트로 캡처하는 작업이 포함됩니다. CQRS는 이벤트를 트리거하는 명령과 이를 사용하는 쿼리를 명확하게 구분하고 이벤트 기반 아키텍처를 촉진하며 변경 사항을 감사하고 재생하기 위한 강력한 메커니즘을 제공함으로써 이벤트 소싱을 보완합니다. 유연성 : CQRS는 애플리케이션의 다양한 부분에 적합한 데이터 저장 메커니즘과 쿼리 모델을 선택할 수 있는 유연성을 제공합니다. 예를 들어, 명령 측에서는 트랜잭션에 최적화된 기존 관계형 데이터베이스를 사용할 수 있고, 쿼리 측에서는 읽기 작업이 많은 워크로드에 최적화된 NoSQL 데이터베이스 또는 복잡한 쿼리를 위한 특수 인덱싱 솔루션을 사용할 수 있습니다. 질문하신 내용을 개념에 대비해서 살펴보면 1,4번에 해당되는 것처럼 도메인 모델이 복잡해지는 것을 피하기 위해 단순 질의를 분리하면 유지보수성과 유연성이 높아 질 수 있습니다. 커맨드 와 질의 에 대한 서버분리를 질문하셨는데 2,3의 최적화와 확장성을 위해서는 각각의 서버(서비스)를 분리하는 것이 효과적이라고 생각합니다. 그리고 로직의 검증을 위한 조회나, 로직상 필요한 조회는 명령의 부분이라고 생각합니다. 감사합니다.
- 0
- 1
- 115
질문&답변
2024.03.26
강의 음성 및 영상
불편을 드려 죄송합니다 😔 제가 음성이 불명확하고 잘린부분을 살펴 금주중으로 보완하는 강의를 업로드 하도록 하겠습니다.
- 0
- 1
- 97
질문&답변
2024.03.13
모듈형 모노리스의 컨테이너화
좀더 상세히 말씀드리면 마이크로서비스가 아닌 모노리스 애플리케이션을 컨테이너화하고 이를 Kubernetes에 배포하는 것은 마이크로서비스로 변환하여 배포하는 장점보다는 못미치지만 그 정도로써의 충분한 이점( 확장성, 배포 및 탄력성 측면에서) 이점을 제공합니다. 장점은 다음과 같습니다. 확장성 : Kubernetes를 사용하면 수요에 따라 컨테이너 인스턴스를 추가하거나 제거하여 애플리케이션을 수평으로 확장할 수 있습니다. Kubernetes에 컨테이너화되고 배포된 모놀리식 애플리케이션을 사용하면 이러한 확장성의 이점을 누릴 수 있습니다. 내부 모듈이 독립적으로 확장되도록 설계된 경우 모놀리스의 개별 구성 요소(모듈)을 쉽게 분리하여 확장하거나 더 많은 컨테이너 인스턴스를 추가하여 전체 모놀리스의 크기를 조정할 수 있습니다. 배포 : Kubernetes는 여러 노드 또는 클러스터에 애플리케이션을 배포하는 기능을 제공합니다. Kubernetes에 모놀리식 애플리케이션을 배포하면 여러 노드에 분산하여 내결함성과 가용성을 향상시킬 수 있습니다. 또한 Kubernetes는 로드 밸런싱 및 서비스 검색과 같은 기능을 제공하여 배포작업을 더욱 향상시킬 수 있습니다. 탄력성 : Kubernetes는 HPA(Horizontal Pod Autoscaler)와 같은 기능을 통해 수요에 따라 컨테이너에 할당된 리소스를 자동으로 조정할 수 있습니다. 즉, 모놀리식 애플리케이션은 트래픽이나 리소스 사용량의 변화에 따라 동적으로 확장하거나 축소할 수 있습니다. 탄력성은 애플리케이션이 성능과 비용 효율성을 유지하면서 리소스를 효율적으로 활용할 수 있도록 보장합니다. 그렇지만 염두에 두어야 할 고려 사항도 있습니다. 복잡성 : Kubernetes에서 모놀리식 애플리케이션을 배포하고 관리하면 기존 모놀리식 서버 아키텍처에 비해 더 많은 복잡성이 발생합니다. 파드, 디플로이, 서비스와 같은 Kubernetes 리소스를 구성하고 관리해야 합니다. 이러한 복잡성으로 인해 학습 곡선과 운영 오버헤드가 증가할 수 있습니다. 리소스 오버헤드 : 컨테이너화 및 Kubernetes에는 약간의 리소스 오버헤드가 수반됩니다. Kubernetes는 컨테이너 관리를 위한 강력한 기능을 제공하지만 효과적으로 작동하려면 리소스도 필요합니다. 애플리케이션의 크기와 복잡성이 단순한 경우에는 Kubernetes로 인한 오버헤드가 정당화되지 않을 수 있습니다. 마이그레이션 노력 : 모놀리식 애플리케이션을 컨테이너화하고 이를 Kubernetes에 배포하려면 특히 애플리케이션이 컨테이너화를 염두에 두고 설계되지 않은 경우 상당한 노력이 필요할 수 있습니다. 컨테이너 친화적으로 만들기 위해 애플리케이션의 일부를 리팩터링해야 할 수도 있는데, 이는 시간이 많이 걸리고 어려울 수 있습니다. 성능 : Kubernetes는 확장성과 탄력성을 제공하지만 특히 분산 환경용으로 설계되지 않은 모놀리식 애플리케이션의 경우 성능에 영향을 미칠 수 있습니다. 구성 요소 간 통신 오버헤드, 네트워크 대기 시간 증가, 리소스 경합 등이 성능에 영향을 미칠 수 있는 요소입니다. 결론적으로, Kubernetes에 모놀리식 애플리케이션을 배포하면 확장성, 배포 및 탄력성 측면에서 이점을 제공할 수 있지만 이점이 관련된 복잡성 및 고려 사항보다 중요한지 신중하게 평가하는 것이 중요합니다. 특정 사용 사례, 요구 사항 및 조직 기능에 따라 Kubernetes가 아키텍처에 가장 적합한 선택일 수도 있고 아닐 수도 있습니다. 결정을 내리기 전에 장단점을 고려하고 대체 접근 방식을 고려하는 것이 중요합니다.
- 1
- 1
- 133
질문&답변
2024.01.14
domain.model.event에 정의되는 객체들에 대한 질문이 있습니다
네 안녕하세요. 항상 저도 프로젝트를 할 때 마다 고민되는 부분을 어려운 질문주셨네요. 움 이러한 관계는 사실 기술 거버넌스에 관한 문제이기도 한 것 같아요. 우선 서비스를 소유하고 있는 조직 또는 팀의 역학관계에 따라 다양한 방안이 고려될 수 있을 것 같네요. 그런 부분을 논한 부분이 도메인 주도 설계의 서비스 매핑 패턴인데 상위스트림 서비스와 하위스트림 서비스 간의 관계를 설명하고 있는데 한번 참고해 보시고요. 그리고 해결방안은 기술 적인 부분보다는 협업의 문제인것 처럼 느껴집니다. 우선 도메인 이벤트를 생산하는 생산자와 이를 소비하는 소비자의 관계는 Contract-First Design 라 는 관점으로 봐야 할 것 같습니다. 이벤트가 아니라 API라고 생각하면 쉬울 것 같네요. 따라서 각 생산자와 소비자는 코드를 직접 수정하기보다는 먼저 명확한 계약이나 인터페이스 사양을 정의하고 유지할 필요가 있겠죠. 참여 팀은 이 계약에 동의하고 이를 준수하고 변경이 필요할 경우 반드시 이전에 합의가 필요할 것 같고요. 또 이것을 중복로 생각할 수 도 있을 것 같은데요. 마이크로서비스는 서비스의 자율적인 배포를 위해 어느정도의 중복을 통한 느슨한 결합을 추구한다고 생각하셔도 될 것 같네요. ^ ^;;;
- 0
- 1
- 147
질문&답변
2024.01.10
VO 관련 궁금한점
안녕하세요 우선 value object의 생명주기는 불변이니 한번에 생성하고, 삭제되는 성격을 가지고 있습니다. 네 그래서 구현한다면 다음과 같이 하면 됩니다. public class Money { public int value; // Constructor to initialize the value public Money(int value) { this.value = value; } // Method to add the value of another Money object to the current object public void add(Money money) { this.value += money.value; } // Main method for testing public static void main(String[] args) { Money money1 = new Money(10); Money money2 = new Money(20); System.out.println("Before addition:"); System.out.println("Money 1 value: " + money1.value); System.out.println("Money 2 value: " + money2.value); // Add the value of money2 to money1 money1.add(money2); System.out.println("\nAfter addition:"); System.out.println("Money 1 value: " + money1.value); System.out.println("Money 2 value: " + money2.value); } }
- 0
- 1
- 139
질문&답변
2024.01.04
VO에 대해서 질문있습니다.
안녕하세요. 한정헌입니다. 우선 DDD에서 VO(Value Object)와 엔터티는 서로 다른 목적을 제공하는 두 가지 개념입니다. 먼저 정의를 명확히 해보겠습니다. 값 객체(VO): 값 객체는 개념적 동일성이 없는 도메인의 설명적 측면을 나타내는 객체입니다. 즉, 변경할 수 없으며 동일한 값을 가진 두 개의 값 개체가 동일한 것으로 간주됩니다. VO는 응집력이 높고 자주 변경되지 않는 속성에 사용되는 경우가 많습니다. 엔티티: 엔터티는 시간과 다양한 상태를 통해 실행되는 고유한 ID를 갖는 객체입니다. 이는 종종 라이프사이클이 있는 비즈니스 객체를 나타냅니다. 엔터티는 변경 가능합니다. 즉, 엔터티 상태는 시간이 지남에 따라 변경될 수 있습니다. 그럼 자주 변경되지만 응집력이 높은 값에 대한 질문에 대해 말씀드리면: 값이 자주 변경되지만 응집력이 높은 경우 Value Object보다는 Entity를 사용하는 것이 더 적절할 수 있습니다. 편집 기능이 필요하고 값이 변경될 수 있는 경우 엔터티를 사용하는 것이 합리적인 선택입니다. 엔터티는 변경 가능하므로 필요에 따라 상태를 수정할 수 있습니다. 그러나 Id 개념을 신중하게 고려해봐야 합니다. 즉 시간이 지나도 변화하는 값이 여전히 동일한 개념적 엔터티를 나타내는 경우에 엔터티를 사용하는 것이 적절합니다. 요약하자면, 엔터티와 값 개체 사용 간의 결정은 값의 개념적 동일성과 값이 변경 가능해야 하는지 불변이어야 하는지 여부에 따라 달라집니다. 값이 고유한 ID를 나타내고 편집해야 하는 경우 엔터티가 더 적합할 가능성이 높습니다. 값이 설명적이고 응집력이 높은 경우에도 일정하게 유지되어야 하는 경우 Value Object 가 답이고요. ㅎ 좀 설명이 계속 개념적일 수 밖에 없네요. 구체적인 사례,예를 주시면 좀더 고민해 볼 수 있을 것 같네요. 감사합니다.
- 0
- 1
- 151
질문&답변
2023.12.06
수업에 사용한 소스코드 문의
네 안녕하세요. 실제 작성해 보는 것이 좋은 것 같아서 교재에 소스코드는 공유하지 않았지만 완성된 코드는 다음 위치에 있습니다. https://github.com/cnaps/MemberMS https://github.com/cnaps/BestBookMS https://github.com/cnaps/BookMS https://github.com/cnaps/RentMS 감사합니다.
- 0
- 1
- 312
질문&답변
2023.12.05
도메인, 바운디드 컨텍스트 관련해서 궁금합니다.
움 저도 공부하면서 이러한 부분이 많이 헷갈렸는데요. 우선 서브도메인과 바운디드 컨텐스트간의 차이를 명확히 정의해야 하는데 다음과 같습니다. 하위 도메인: 하위 도메인은 비즈니스의 뚜렷하고 응집력 있고 잘 정의된 측면을 나타내는 전체 비즈니스 도메인의 일부입니다. 이는 크고 복잡한 문제 공간을 더 작고 관리하기 쉬운 조각으로 나누는 방법입니다. 하위 도메인은 비즈니스 기능과 비즈니스 내의 자연스러운 구분을 기반으로 식별됩니다. 바운디드 컨텍스트: BC는 특정 모델이 정의되고 적용 가능한 특정 경계입니다. 여기에는 해당 경계 내에서 특정 의미를 갖는 일련의 개념, 용어 및 규칙이 포함됩니다. BC는 서로 다른 모델 간의 언어적, 개념적 경계를 관리하는 것입니다. 이는 시스템의 여러 부분이 동일한 개념에 대해 서로 다른 해석을 할 때 발생할 수 있는 모호함과 충돌을 피하는 데 도움이 됩니다. 본질적으로 하위 도메인은 비즈니스 문제 공간의 논리적 파티션 인 반면, BC는 해당 문제 공간의 일부를 해결하기 위해 정의된 특정 모델이 있는 논리적 경계입 니다. BC를 도입하는 목적은 시스템의 서로 다른 부분에 있는 모델이 서로 간섭하지 않고 주어진 컨텍스트 내에서 명확성과 일관성이 있는지 확인하는 것입니다. 설명을 위해 전자상거래 시스템을 생각해 보세요. 하위 도메인: 주문 처리, 재고 관리, 고객 관계 관리 및 배송은 전자 상거래 비즈니스 내에서 별개의 하위 도메인이 될 수 있습니다. BC: "주문 처리" 하위 도메인 내에는 주문 접수, 결제 관리, 배송 물류 처리를 위한 다양한 제한된 컨텍스트가 있을 수 있습니다. 이러한 각 컨텍스트에는 해당 범위에 특정한 자체 모델, 용어 및 규칙이 있습니다. 요약하면, 하위 도메인은 문제 공간의 논리적 구분을 나타내는 반면, 제한된 컨텍스트는 해당 하위 도메인의 특정 측면을 다루고 해결하기 위해 모델이 정의되는 명확하고 명시적인 경계를 설정합니다. 따라서 분석 설계를 위해 하위도메인을 가지고 도메인를 파악하고 BC로 도메인 분석/설계 결과를 정리할 수 있습니다. 그럼 원래 질문인 부분으로 넘어가서 답변 드리면 BC와 하위 도메인 간의 1:1 관계: BC가 반드시 하위 도메인과 1:1 관계를 가질 필요는 없습니다. 하위 도메인은 여러 개의 BC에 걸쳐 있을 수 있으며 BC는 여러 하위 도메인을 포함할 수 있습니다. 핵심은 BC 내에서 모델이 일관되고 명확하도록 보장하는 것입니다. 하위 도메인 내의 여러 바인딩된 BC: 하위 도메인 내에 여러 개의 BC가 있을 수 있습니다. 특히 하위 도메인의 서로 다른 부분에 고유한 모델이나 컨텍스트가 다른 경우 더욱 그렇습니다. 하위 도메인 내의 각 BC는 비즈니스 문제의 특정 측면을 캡슐화합니다. BC 내의 하위 도메인: BC는 하위 도메인과 연결되는 경우가 많지만 엄격한 규칙은 아닙니다. BC는 시스템의 복잡성과 요구 사항에 따라 하나 이상의 하위 도메인을 포함할 수 있습니다. 하위 도메인 내의 다른 소규모 도메인: DDD에서 "하위 도메인"이라는 용어는 일반적으로 비즈니스 문제의 논리적으로 응집력 있고 별개의 부분을 나타냅니다. 하위 도메인 내에는 "작은 도메인"이 없을 수도 있지만 하위 도메인 내에서 모델링되는 다양한 영역이나 측면이 있을 수 있습니다. 이상입니다. 적절한 답변이 되었기를 바랍니다. 🙇♂
- 0
- 1
- 197