쵸코쿠키의 연습장

헥사고날 아키텍처 전술적 설계는 이전 차시에서 헥사고날 아키텍처로 설명했던 마이크로서비스의 가장 안쪽의 도메인 모델을 설계합니다. 그 다음은 도메인 모듈, 그리고 마이크로서비스를 설계를 합니다. 이 헥사고날 아키텍처는 고유한 비즈니스의 개념을 표현하는 도메인 모델과 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를 통해서만 호출할 수 있습니다. 따라서 이런 구조에서 분산 트랜잭션 문제가 발생할 수 있습니다. 여러 서비스 간에 데이터 일관성을 유지하는 방법 두 개의 서비스에 걸쳐서 트랜잭션 처리가 필요한 업무가 있을 수 있습니다. 즉 여러 서비스 간의 데이터 일관성을 유지할 필요가 있습니다. 이런 분산 트랜잭션 처..

마이크로 서비스 통신 방법 Rest API는 클라이언트에서 서버 쪽에 존재하는 마이크로서비스를 호출할 때 기본 통신방법이 되며, 다양한 클라이언트 채널 연계나 외부에 API의 공개를 원활하게 하기 위한 방법으로는 API G/W를 사용하는 것을 살펴봤습니다. 제일 먼저 검토해야 할 방법은 Rest API 같은 동기식 호출입니다. Sync 방식이라고도 합니다. 동기식 호출은 Request를 하면 바로 Response가 오는 방식을 말합니다.모바일 UI에서 상품서비스에 Post 방식의 요청을 하고, 상품은 주문 서비스에 Get 방식의 동기호출을 하고 있습니다. 그에 따라 바로 응답이 발생하고, 200이라는 OK 코드도 받아오는 것을 볼 수 있습니다. 바로 요청하면 응답이 오는 패턴이기 때문에 가장 많이 쓰이는..

Presentation Layer Presentation Layer에서 가장 많이 쓰이는 패턴은 Model View Controller로 이루어진 MVC 패턴입니다. MVC 모델은 초기 컨트롤러와 모델이 어떤 기술을 쓰느냐에 따라 발전해왔습니다. 최근에는 JSP가 View의 역할을, POJO가 모델의 역할, 서블릿이 이 두 개의 요소를 연계하는 컨트롤러의 역할을 수행하는 방식으로 발전해왔습니다. 그렇지만 현재는 JSP 서블릿뿐만 아니라 웹, 모바일, 태블릿, 인터넷, PC, 셋톱박스와 같은 다양한 인터페이스의 등장으로 인해서 이를 지원하기 위한 다양한 화면 플랫폼이 등장했습니다. Spring의 Thymeleaf나 페이스북이 공개한 React, 기존에 유명했던 ANGULARJS, 그리고 Vue.js 등의 ..

Layer 간의 의존성 UI 클라이언트가 Presentation Layer를 이용하고, Presentation 층이 Business Logic 층을 호출하고, Business Logic 층이 Data Access 층을 호출하고, Data Access 층이 저장소를 접근하게 됩니다. 어플리케이션에서 모든 영역이 중요하겠지만 가장 핵심적인 부분은 아무래도 어플리케이션이 제공하는 주요 서비스의 업무 로직을 담고 있는 Business Logic 층입니다. Presentation 층과 Data Access 층은 기술 트렌드에 따라 다양하게 교체 변화 가능하나, 핵심 비즈니스 기능은 한 번 정의되면 잘 변경되지 않습니다. 따라서 시스템의 확장성과 유연성을 높이기 위해 Layered Architecture는 이러한 ..

Tier와 Layer Tier는 물리층을 의미하며, Layer는 논리층을 의미합니다. Tier는 물리적인 장비, 서버 컴퓨터가 될 수 있습니다. Layer는 이러한 Tier 내부의 논리적인 분할을 의미합니다. 1:1이 될 수도 있지만 Tier의 내부를 제공하는 기능 성격에 따라 논리적 구분을 할 수 있습니다. 여기 어플리케이션 서버라는 중간층은 세 가지 Layer로 구별될 수 있습니다. 가장 일반적인 어플리케이션 Layer인 Presentation, Business Logic, Data Access층으로 나눠질 수 있습니다. Layered Architecture Layered Architecture는 설계자들이 복잡한 시스템을 분리할 때 흔히 사용하는 패턴 중 하나로 상위는 하위를 호출하여, 상위는 하위..

어플리케이션 아키텍처 우선 마이크로서비스 Architecture를 내외부로 구분했을 때 외부 Architecture가 Architecture를 이루는 구성요소의 관계를 설명한다면, 내부 Architecture는 구성요소 자신의 내부 구조를 상세히 정의하는 것을 말합니다. 이런 어플리케이션의 내부 구조를 정의하는 활동을 Application Architecture라고 하는데요. 마이크로서비스의 Inner Architecture, 다른 말로 하면 Application Architecture에 대해 자세히 살펴보도록 하겠습니다. Application Architecture는 어플리케이션이 동작하는 구조, 즉 동작하는 공통 메커니즘을 정의하는 것입니다. 웹 어플리케이션 구조 클라이언트 쪽에 브라우저 및 모바일 ..

인증, 인가 API 게이트웨이에서 인증 인가를 처리할 수 있습니다. 그런데 그것은 자체 기능으로 처리하지 않고 OAuth 서비스를 사용합니다. OAuth는 각각의 리소스 서비스가 자체적으로 인증 인가를 처리하는 것이 비효율적이고 독립성을 떨어뜨리기 때문에 등장한 서비스입니다. 동작 메커니즘을 살펴보면 우선 사용자가 API 게이트웨이를 통해 OAuth에게 각 서비스 리소스에 액세스할 권한이 있는지 요청합니다. 그럼 OAuth 서비스는 인증된 사용자인지 이 리소스에 권한이 있는지 확인하고 그것이 확인됐다면 리소스에 접근 가능한 증명서인 액세스 토큰을 발급해 줍니다. 그러면 API 게이트웨이는 다시 요청을 준비하고 각각의 리소스 서비스는 이런 리퀘스트가 액세스 토큰이 있는지 판단하여 리소스를 허용하는 것입니다..

마이크로 서비스의 역사 우선 기반 서비스가 어떠한 과정을 거쳐서 발전되었는지 마이크로서비스 발전 과정을 살펴보도록 하겠습니다. 그때부터 소프트웨어 업계가 거대한 계획이나 프로세스 대신 빠른 실패와 피드백을 기반으로 하는 실용적인 실천 방법을 선호하게 되었습니다. 우선 AWS가 IaaS 개념으로 2006년도에 EC2를 발표했고 넷플릭스가 스트리밍 사업을 시작하고 아마존의 클라우드 서비스인 AWS로 시스템을 이동하기 시작했습니다. 그러다가 데이터베이스 스토리지가 한 번 크게 망가져서 서비스가 큰 장애를 겪게 됩니다. 이걸 계기로 넷플릭스는 큰 덩어리의 모노리식 시스템에서 마이크로서비스 기반의 시스템으로의 전환을 시작했다고 합니다. 그런데 넷플릭스는 그런 마이크로서비스 기반 시스템을 만들고 운영하면서 여러 어..