쵸코쿠키의 연습장

쇼피몽 서비스 업무 흐름 마이크로서비스들 간의 동기 및 비동기 연동 기능을 구현해서 고객이 상품을 구매하는 쇼핑몰 시스템의 주요 프로세스를 구현하고 테스트해 보았습니다. 이 쇼핑몰 시스템의 여러 업무 중 상품 구매를 위한 프로세스를 구현합니다. 이 프로세스를 좀 더 자세히 설명하면, 구매자가 상품구매를 위해 구매할 상품과 수량을 입력하면 Account 서비스로 구매자에 해당하는 주소정보를 조회해서 가져옵니다. Product 서비스로 구매하려는 상품의 가격정보를 조회해서 가져옵니다. 구매자가 가져온 주소와 상품의 가격을 확인하고 최종 구매를 결정하면, 이 정보가 배송 서비스로 전달됩니다. 이 상품 구매 프로세스를 동작하게 하기 위한 각 서비스간의 동기 및 비동기 방식의 연동 기능을 구현하고 테스트합니다. ..

업무기능 추가 Account에 간단하게 아이디와 이름, 주소와 이메일 주소만을 갖는 간단한 객체로 설계하고 구현을 해보았습니다. 모델이 코드로 어떻게 구현되는지 또 어떻게 테스트해 볼 수 있는지 이해할 수 있었습니다. 그래서 이번에는 Account Domain Model 전체로 확장해서 구현하고 테스트를 해보았습니다. 초기 하나의 문자열 정보로 관리했던 주소는 주소와 우편번호로 구체화하여 별도 객체로 분리하였습니다. 또한 쇼핑몰 서비스를 사용하는 회원은 판매자, 구매자로 회원 유형을 분리하였고, 또한 판매나 구매 실적에 따라 등급이 부여될 수 있어야 하므로 별도 MembershipLevel을 추가합니다. 따라서 초기의 간단했던 Account는 화면과 같이 Account, Address, Membertyp..

Swagger를 활용한 API 명세 & 테스트 Swagger는 간단한 설정으로 프로젝트에서 지정한 URL들을 HTML화면으로 확인할 수 있게 해주는 오픈소스 프로젝트입니다. 특히 REST API를 만드는 경우 주소나 파라미터가 변경되더라도 그 변경된 소스를 그대로 참조 문서로 만들어줍니다. 따라서 API가 수정되더라도 이 API를 이용하는 개발자는 문서를 참조하고 또 쉽게 테스트를 할 수 있습니다. 따라서 Swagger를 통해 API를 테스트하기 위해 pom.xml 파일에 화면과 같이 추가합니다. Config 패키지에 SwaggerConfig 클래스 스프링 부트 프로젝트에 추가하였습니다. 마지막으로 Application의 Swagger 어노테이션을 추가합니다. 소스코드가 변경되었으니 프로젝트를 다시 Bu..

Spring Boot Project 생성 실제 소스코드를 구현하기 위해 Spring Boot 프로젝트를 생성하고 Maven에 의존성, 즉 Dependency를 추가합니다. 이렇게 프로젝트를 만들고 개발을 위한 설정이 끝나면 구현을 위한 소스코드 패키지의 구조를 정의하고, 이후 하나씩 구현을 진행합니다. Spring Boot 프로젝트는 New - Starter Project를 선택하면 New Spring Starter Project 화면이 출력되는데, 이 화면의 Name, Location, Group, Artifact를 화면과 같이 입력합니다. 그리고 Next 버튼을 누르면 프로젝트의 Dependency를 추가하는 화면으로 전환되는데, Spring Boot Version을 선택합니다. 프로젝트에서 사용할 ..

개발환경 구축 마이크로서비스를 구현하기 위해 오픈소스를 활용한 개발환경을 구축해보도록 하겠습니다. 개발환경은 JDK, STS, Lombok, Maven의 순서로 설치를 합니다. 본 강의의 실습을 위해 JDK와 STS를 설치합니다. 그리고 자바에서 도메인 객체를 만들 때 프로퍼티에 대한 Getter, Setter 그리고 ToString, 생성자들을 객체마다 반복적으로 만들어야 합니다. 이런 반복적인 코드들을 어노테이션 선언만으로 자동 생성해 주는 라이브러리인 Lombok도 설치합니다. 그리고 Build 도구는 Maven을 사용합니다. JDK 설치 JDK는 오라클 사이트의 다운로드 메뉴에서 자신의 운영체제와 맞는 버전을 다운로드 받아서 설치합니다. 실습에 사용하는 컴퓨터는 64비트 운영체제로, 64비트용 J..

쇼핑몰 서비스 업무 흐름 쇼핑몰 서비스의 업무 흐름은 가장 기본적인 구매자의 제품 구매 사례 관점에 대해 알아보겠습니다. 구매자는 구매하고자 하는 상품과 구매 수량을 입력해서 상품을 주문하고, 주문한 상품의 배송상태를 확인합니다. 식별한 마이크로서비스들 간의 업무 흐름으로, 먼저 구매자는 상품 구매를 하기 위해서 화면을 통해 구매하려는 상품과 구매 수량을 입력합니다. 구매 정보가 입력되면 Account 서비스로 구매자 이름으로 입력된 사람이 회원인지 아닌지 확인합니다. Account 서비스에 구매한 상품의 배송을 위한 주소를 가져와 상품을 배송 받을 주소로 설정합니다. 그리고 구매하기 위해 입력한 상품 이름으로 Product 서비스에서 해당 상품의 가격이 얼마인지 요청해서 전달 받은 후 입력한 구매수량에..

애그리게잇 도메인 객체의 관리는 객체의 생명주기 동안 무결성을 유지하고 생명주기 관리를 위해 객체의 관계가 복잡해지는 것을 최소화하는 것이 중요합니다. 따라서 업무상 관련 있는 객체들을 묶어 경계를 명확히 정의해서 객체 간 관계가 복잡해지지 않도록 생명주기 전 단계에서 도메인 객체의 무결성을 유지할 수 있게 해주는 Aggregate을 정의해야 합니다. Aggregate은 업무상 관련 있는 객체들을 모아 경계를 명확히 정의하여 객체 간 관계를 복잡하지 않게 합니다. 생명주기 상의 전 단계에서 도메인 객체의 무결성을 유지할 수 있게 해주는 패턴입니다. 한마디로 표현하면, 데이터 변경의 단위로 다루는 연관된 객체의 묶음입니다. Aggregate은 1개 이상의 Entity로 구성됩니다. 그 중 한 Entity는..

헥사고날 아키텍처 전술적 설계는 이전 차시에서 헥사고날 아키텍처로 설명했던 마이크로서비스의 가장 안쪽의 도메인 모델을 설계합니다. 그 다음은 도메인 모듈, 그리고 마이크로서비스를 설계를 합니다. 이 헥사고날 아키텍처는 고유한 비즈니스의 개념을 표현하는 도메인 모델과 UI, 데이터베이스 등의 기술을 분리합니다. 도메인과 기술의 분리는 빠르게 변화하는 기술의 변경과 대체를 쉽고 빠르게 수행할 수 있습니다. 그럼 모델링을 하기에 앞서 모델 패키지 구조를 Model, Repository, Service로 구성하고, 그리고 실제 도메인 모델이 그려질 다이어그램이 위치합니다. Domain 안의 Model이라는 패키지 안에는 도메인 모델을 구성하는 Entity, 값 객체, 표준 타입의 도메인 모델들이 위치합니다. 이..

마이크로 서비스 내부 설계를 위한 전술적 설계 및 주요 개념 마이크로서비스는 도메인의 개념을 명확하고 자세히 표현하는 도메인 모델링을 통해 코드로 구현합니다. 즉, 전술적 설계란 전략적 설계를 통해 도출된 마이크로서비스의 내부를 상세히 설계하는 활동입니다. 전술적 설계는 도메인 주도 설계 개념에 나오는 용어로 비즈니스의 고유한 활동을 정확하게 모델링하는 설계 패턴과 방법입니다. 설계자는 이 절차와 다양한 기법들을 활용해서 개발하려는 서비스의 개념과 동작을 모델로 표현합니다. 이 전술적 설계의 진행 절차와 방법은 이전의 전략적 설계를 통해 식별했던 6개의 마이크로서비스로 구성된 쇼핑몰 시스템을 예제로 설명을 드리도록 하겠습니다. 마이크로 서비스의 내부 구조 마이크로서비스를 표현하는 6각형의 도형이 있습니다..

엔티티 / 애그리게잇 이 entity라는 것은 이벤트 수행 결과를 표현하는 데이터, 저장하는 데이터입니다. 이 entity aggregate 이름은 노란색 스티커에 작성해서 command과 도메인 이벤트 짝의 위쪽에 살짝 겹치도록 붙이게 됩니다. 이렇게 command, 도메인 이벤트에서 entity aggregate을 찾는 동안 새로운 도메인 이벤트를 발견할 수 있습니다. 이런 경우도 발견하는 즉시 모델링 공간 내의 흐름에 맞는 위치에 작성해서 붙이면 됩니다. change account command와 account changed 도메인 이벤트의 account에 대한 변경 요청과 변경이 수행되었다는 이벤트의 짝으로 account로 작성해서 붙일 수 있습니다. 마찬가지로 request purchase와 p..

이벤트 스토밍 이벤트 스토밍은 도메인 이벤트를 찾는 활동으로 시작을 했습니다. 도메인 이벤트를 동작하게 하는 command를 찾는 활동에 대해 알아보겠습니다. 커맨드 command는 도메인 이벤트를 발생시키는, 즉 도메인 이벤트를 동작하게 하는 명령입니다. 이 command의 이름은 change account, request shipment와 같이 명령어의 형태로 작성을 합니다. 찾은 command의 이름은 파란색 스티커에 작성을 해서 이 command과 연관된 도메인 이벤트의 왼쪽에 붙입니다. account changed라는 도메인 이벤트를 동작하게 하는 만드는 command으로 change account를 적어서 account changed 스티커의 왼쪽에 붙입니다. 이 방법으로 account reg..

쇼핑몰 서비스 이 쇼핑몰 서비스는 상품을 판매하는 사람과 구매하는 사람을 이어주는 서비스입니다. 이 서비스는 판매자가 상품을 온라인으로 팔기 위해 쇼핑몰 서비스에 상품을 등록합니다. 이 상품이 필요한 사람이 상품을 주문하면 판매자는 구매한 사람에게 상품을 배송합니다. 이후 구매자가 상품을 받으면 구매를 확정하는 일반적인 쇼핑몰 서비스입니다. 이 서비스의 사용자는 상품 판매자와 상품 구매자로, 상품 판매자는 판매하고자 하는 상품을 쇼핑몰 서비스에 등록합니다. 판매가 된 상품을 구매자에게 발송하는 업무 그리고 상품 구매자는 상품 판매자가 등록해놓은 상품을 구매합니다. 상품이 도착하면 최종 구매를 완료하게 됩니다. 이벤트 스토밍은 도메인의 이벤트를 찾는 것으로부터 시작합니다. 이 도메인 이벤트를 찾을 때에는 ..

전략적 설계 설계를 진행하면서 계속해서 개념들이 쌓여 설계가 점점 커지게 되면 중요한 것과 덜 중요한 것들을 찾아서 분할을 해야합니다. 소프트웨어를 개발하려고 하는 큰 도메인을 논리적으로 분리해서 핵심, 지원, 일반 서브도메인으로 나눕니다. 서브도메인에서 바운디드 텍스트를 도출하게 되는데 이때 서브도메인과 바운디드 컨텍스트는 1:1 또는 1:N으로 도출이 될 수 있습니다. 이렇게 찾아진 컨텍스트들 간의 관계를 찾아 컨텍스트 맵을 그릴 수 있습니다. 최종적으로 마이크로서비스를 도출할 수 있습니다. 효과적인 설계에 대한 요구 소프트웨어의 전반적인 목적은 특정 도메인의 일이 더 잘 동작하도록 하는 데 있습니다. 따라서 소프트웨어는 도메인을 정확히 구현해야 된다고 말씀을 드릴 수 있습니다. 도메인 주도 설계는 ..

도메인 모델의 표준 패턴 다이어그램과 같은 도메인 모델을 그리기 위해서 알아야 될 도메인 모델의 표준 패턴에 대해 알아보도록 하겠습니다. 전술적 설계를 위한 모델 주도 설계의 내비게이션 맵으로 도메인 모델을 위해 사용하는 표준 패턴과 각 패턴과의 관계를 나타낸 그림입니다. 이런 표준 패턴을 사용해서 도메인 모델링을 하게 되면 다른 사람의 업무, 다른 팀의 업무를 쉽게 이해할 수 있는 설계의 체계를 가져갈 수 있습니다. 따라서 훌륭한 도메인 모델을 개발하기 위해 화면과 같은 표준 패턴에 대해 이해를 하고 있어야 됩니다. 계층형 아키텍처와 도메인 모델의 표준 패턴, 도메인을 표현하기 위한 표준 패턴 중 전술적 설계에서 반드시 이해해야 되는 패턴들이 있습니다. 계층형 아키텍처 소프트웨어를 만들 때 개발되는 시..

컨텍스트 매핑 여러 개의 Bounded Context들은 비즈니스의 문제 해결을 위해 상호 간에 연동이 필요하게 되됩니다. 이런 경우 두 Bounded Context 사이에 선을 그려서 두 Bounded Context가 관계를 갖고 있다는 것을 표시합니다. 서로 다른 Bounded Context를 담당하는 팀에서는 각각의 유비쿼터스 언어를 정의해서 사용하게 됩니다. 이 선은 두 Bounded Context가 갖고 있는 각각의 유비쿼터스 언어 사이의 통역, 번역을 의미한다고 할 수 있습니다. Bounded Context 사이의 관계를 찾아 매핑할 때 두 Bounded Context 사이의 선이 어떤 종류의 관계인지를 찾는 것이 매우 중요합니다. 두 영역 간의 경계와 그 사이의 관계를 잘 정의합니다. 시간에..

도메인 주도 설계 소프트웨어에서 효과적인 설계는 매우 중요합니다. 도메인 주도 설계에서는 설계를 효과적으로 수행할 수 있도록 마이크로서비스를 식별해내는 전략적 설계와 식별된 마이크로서비스의 내부를 상세히 설계하는 전술적 설계로 설계를 두 개의 단계로 설명하고 있습니다. 상세한 설계에 들어가기에 앞서 전략적 설계를 수행합니다. 전략적 설계는 마이크로서비스 도출을 위해서 비즈니스 상 전략적으로 중요한 것을 찾아 중요도에 따라 이를 나누는 방법을 설명하고 있습니다. 전략적 설계 이런 전략적 설계를 수행하기 위해 중요한 두 가지가 있는데, 첫 번째는 도메인의 주요 개념을 정의하고 도메인 간의 경계를 식별하는 Bounded Context가 있습니다. 그리고 두 번째는 프로젝트를 수행하는 모든 팀원이 공통으로 사용..

소프트웨어 본질 소프트웨어 본질은 해당 소프트웨어 사용자들을 위해 복잡한 도메인에 관련된 문제들을 해결하는 데 있습니다. 복잡한 도메인을 소프트웨어로 구현하기 위해서는 해당 도메인을 바르게 이해해야 되는데, 도메인 전문가와 개발자 등 프로젝트에 참여한 모든 구성원들은 도메인의 올바른 이해를 위해 많은 노력을 해야 됩니다. 그러나 보통의 프로젝트에서는 비용과 일정, 인력 등 리소스 관리를 중요시하고 있습니다. 특히 개발자들도 도메인에 대한 이해보다는 UI, Framework, DB 등 최신 기술을 습득하고 적용하는 것에만 관심이 많은 것이 사실입니다. 그러므로 도메인의 문제를 해결할 수 있는 올바른 소프트웨어를 개발하기 위한 도메인 주도 설계에 대해 알아보겠습니다. 도메인 주도 설계 도메인이란 비즈니스나 ..

도메인 주도 설계 가변적인 클라우드 인프라 위의 어플리케이션인 마이크로서비스는 그 아키텍처에 특히 유연성과 확장성을 강조하고 있습니다. 이벤트 주도 설계를 통해서도 살펴보았지만 서비스를 제공하는 각 서비스 간의 관계는 서비스가 독립적입니다. 대체가능하도록 느슨하고 유연하게 구조화되어 있어야 합니다. 또한 헥사고날 아키텍처를 통해 살펴본 것처럼 서비스 내부의 구조도 시스템의 유연성과 확장성을 높여야 합니다. 그러기 위해 기술과 비즈니스 로직을 분리하여 구축하는 것이 바람직합니다. 어떻게 각각의 서비스를 비즈니스 독립적으로 식별할 수 있냐는 것과 또 하나는 서비스 내부 구조화 측면에서 어떻게 기술과 독립된 비즈 모델을 잘 설계할 수 있느냐 하는 질문이 있습니다. 이러한 질문에 답을 주는 아주 유용한 도구가 ..

CQRS(Command Query Responsibility Segregation : 명령 조회 책임 분리 서비스의 성능향상을 위해 서비스 Instance를 Scale Out하여 여러 개로 실행한 경우에 데이터 읽기/업데이트 작업으로 인한 리소스 교착 상태가 발생할 수가 있습니다. CQRS 패턴이라고 합니다. Command Query Responsibility Segregation, 명령 조회 책임 분리 패턴입니다. CQRS는 기존의 일반적인 개념이었던 동일한 저장소에 데이터를 넣고, 입력/수정/삭제/조회하는 방식에 도전하는 흥미로운 패러다임을 도입하고 있습니다. 일반적으로 사용자의 비즈니스 요청은 시스템 상태를 변경하는 명령과 시스템의 상태를 가져오는 조회의 두 부분으로 크게 나눌 수 있습니다. 사실 ..

서비스별 데이터베이스 Soa와 구분되는 Msa 특징으로 각각의 마이크로서비스는 각자의 비즈니스 처리를 위한 영구 데이터를 소유하고 있다는 것입니다. 그렇기 때문에 이러한 소유한 데이터는 다른 서비스에 직접 호출되게 하지 않고, 자신의 API를 통해서만 액세스 할 수 있습니다. 주문서비스가 주문수행을 위해 고객 정보를 필요로 한다면, 바로 고객 테이블을 질의를 할 수 없습니다. 반드시 고객 서비스의 API를 통해서만 호출할 수 있습니다. 따라서 이런 구조에서 분산 트랜잭션 문제가 발생할 수 있습니다. 여러 서비스 간에 데이터 일관성을 유지하는 방법 두 개의 서비스에 걸쳐서 트랜잭션 처리가 필요한 업무가 있을 수 있습니다. 즉 여러 서비스 간의 데이터 일관성을 유지할 필요가 있습니다. 이런 분산 트랜잭션 처..