1장. 이벤트 기반 마이크로서비스를 사용해야 하는 이유
매체는 메시지이다.
마샬 맥루한
맥루한은 인류에게 영향을 미치고 사회에 근본적인 변화를 가져오는 것은 미디어의 콘텐츠 가 아니라 미디어와의 참여 라고 주장합니다 . 신문, 라디오, 텔레비전, 인터넷, 인스턴트 메시징, 소셜 미디어는 모두 우리의 집단적 참여 덕분에 인간 상호 작용과 사회 구조를 변화시켰습니다 .
컴퓨터 시스템 아키텍처에서도 마찬가지입니다. 네트워크 통신, 관계형 데이터베이스, 빅 데이터 개발 및 클라우드 컴퓨팅이 아키텍처 구축 방식과 작업 수행 방식을 어떻게 크게 변화시켰는지 확인하려면 컴퓨팅 발명의 역사를 살펴보기만 하면 됩니다. 이러한 각각의 발명은 다양한 소프트웨어 프로젝트에서 기술이 사용되는 방식뿐만 아니라 조직, 팀 및 사람들이 서로 통신하는 방식도 변화시켰습니다. 중앙 집중식 메인프레임에서 분산형 모바일 애플리케이션에 이르기까지 각각의 새로운 매체는 사람들과 컴퓨팅의 관계를 근본적으로 변화시켰습니다.
비동기적으로 생산되고 소비되는 이벤트의 매체는 현대 기술에 의해 근본적으로 변화되었습니다. 이제 이러한 이벤트는 매우 큰 규모로 무기한 지속될 수 있으며 필요한 만큼 여러 번 모든 서비스에서 사용될 수 있습니다. 컴퓨팅 리소스는 온디맨드 방식으로 쉽게 획득하고 해제할 수 있으므로 마이크로서비스를 쉽게 생성하고 관리할 수 있습니다. 마이크로서비스는 필요에 따라 데이터를 저장하고 관리할 수 있으며, 이전에는 배치 기반 빅데이터 솔루션으로 제한되었던 규모로 이를 수행할 수 있습니다. 소박하고 단순한 이벤트 중심 매체에 대한 이러한 개선은 컴퓨터 아키텍처를 변화시킬 뿐만 아니라 팀, 사람 및 조직이 시스템과 비즈니스를 생성하는 방식을 완전히 바꾸는 광범위한 영향을 미칩니다.
이벤트 기반 마이크로서비스란 무엇입니까?
마이크로서비스와 마이크로서비스 스타일 아키텍처는 수년 동안 다양한 이름으로 다양한 형태로 존재해 왔습니다.SOA(서비스 지향 아키텍처)는 서로 동기적으로 직접 통신하는 여러 마이크로서비스로 구성되는 경우가 많습니다.메시지 전달 아키텍처는 소비 가능 이벤트를 사용하여 서로 비동기적으로 통신합니다. 이벤트 기반 커뮤니케이션은 확실히 새로운 것은 아니지만 대규모 데이터 세트를 실시간으로 처리해야 하는 필요성은 새로운 것이며 기존 아키텍처 스타일의 변화가 필요합니다.
최신 이벤트 기반 마이크로서비스 아키텍처에서 시스템은 이벤트를 발행하고 소비하여 통신합니다. 이러한 이벤트는 메시지 전달 시스템처럼 소비 시 삭제되지 않지만 대신 다른 소비자가 필요에 따라 읽을 수 있도록 유지됩니다. 이는 이 책에서 다루는 매우 강력한 패턴을 허용하므로 중요한 차이점입니다.
서비스 자체는 소규모이며 조직의 필요한 비즈니스 목표를 달성하는 데 도움이 되도록 특별히 제작되었습니다. "작은"의 일반적인 정의는 작성하는 데 2주 이상 걸리지 않는 것입니다. 또 다른 정의에 따르면, 서비스는 (개념적으로) 자신의 머리 속에 들어갈 수 있어야 합니다. 이러한 서비스는 입력 이벤트 스트림의 이벤트를 사용합니다. 특정 비즈니스 로직을 적용합니다. 자체 출력 이벤트를 내보내거나, 요청-응답 액세스를 위한 데이터를 제공하거나, 타사 API와 통신하거나, 기타 필요한 작업을 수행할 수 있습니다. 이 책에서 자세히 설명하겠지만 이러한 서비스는 상태 저장형 또는 비상태형, 복잡하거나 단순할 수 있습니다. 장기 실행 독립형 애플리케이션으로 구현되거나 Functions-as-a-Service를 사용하여 기능으로 실행될 수 있습니다.
이벤트 스트림과 마이크로서비스의 이러한 조합은 비즈니스 조직 전반에 걸쳐 상호 연결된 활동 그래프를 형성합니다.단일체와 단일체 간 통신으로 구성된 전통적인 컴퓨터 아키텍처는 유사한 그래프 구조를 가지고 있습니다. 이 두 그래프는 모두 그림 1-1 에 나와 있습니다 .
이 그래프 구조를 효율적으로 작동시키는 방법을 식별하려면 노드와 연결이라는 두 가지 주요 구성 요소를 살펴봐야 합니다. 이 장에서는 각각을 차례로 살펴보겠습니다.
도메인 기반 설계 및 제한된 컨텍스트 소개
Eric Evans가 같은 제목의 책에서 만든 도메인 중심 설계는 이벤트 중심 마이크로서비스를 구축하는 데 필요한 몇 가지 개념을 소개합니다. 이 주제에 관해 쉽게 이야기할 수 있는 기사 , 책 , 이달의 블로그가 많기 때문에 이 섹션은 간략하게 설명하겠습니다.
다음 개념은 도메인 중심 설계를 뒷받침합니다.
도메인기업이 점유하고 솔루션을 제공하는 문제 공간입니다. 여기에는 비즈니스가 관련되어 있는지 여부에 관계없이 규칙, 프로세스, 아이디어, 비즈니스 관련 용어 및 문제 공간과 관련된 모든 것을 포함하여 비즈니스가 다투어야 하는 모든 것이 포함됩니다 . 도메인은 사업체의 존재와 관계없이 존재합니다.
하위 도메인기본 도메인의 구성 요소입니다. 각 하위 도메인은 특정 책임 하위 집합에 중점을 두고 있으며 일반적으로 일부 비즈니스 조직 구조(예: 창고, 판매 및 엔지니어링)를 반영합니다. 하위 도메인은 그 자체로 도메인으로 볼 수 있습니다. 도메인 자체와 마찬가지로 하위 도메인도 문제 공간에 속합니다.
도메인(및 하위 도메인) 모델비즈니스 목적에 유용한 실제 도메인의 추상화입니다. 비즈니스에 가장 중요한 도메인의 부분과 속성을 사용하여 모델을 생성합니다. 비즈니스의 주요 도메인 모델은 비즈니스가 고객에게 제공하는 제품, 고객이 제품과 상호 작용하는 인터페이스, 비즈니스가 명시된 목표를 달성하는 데 사용되는 다양한 기타 프로세스 및 기능을 통해 식별할 수 있습니다. 도메인이 변경되고 비즈니스 우선순위가 변경됨에 따라 모델을 구체화해야 하는 경우가 많습니다. 도메인 모델은 비즈니스에서 문제를 해결하기 위해 사용하는 구성이므로 솔루션 공간의 일부입니다.
제한된 컨텍스트하위 도메인과 관련된 입력, 출력, 이벤트, 요구 사항, 프로세스 및 데이터 모델을 포함한 논리적 경계입니다. 이상적으로는 제한된 컨텍스트와 하위 도메인이 완전히 일치하지만 레거시 시스템, 기술 부채 및 타사 통합으로 인해 예외가 발생하는 경우가 많습니다. 제한된 컨텍스트는 솔루션 공간의 속성이기도 하며 마이크로서비스가 서로 상호 작용하는 방식에 중요한 영향을 미칩니다.
제한된 컨텍스트는 응집력이 매우 높아야 합니다. 컨텍스트의 내부 작업은 집중적이고 밀접하게 관련되어 있어야 하며, 대부분의 커뮤니케이션은 경계를 넘어서는 것이 아니라 내부에서 발생합니다. 응집력이 높은 책임을 가지면 설계 범위가 줄어들고 구현이 더 간단해집니다.
하나의 제한된 컨텍스트 내에서 변경된 사항은 인접한 컨텍스트에 대한 영향을 최소화하거나 제거해야 하므로 제한된 컨텍스트 간의 연결은 느슨하게 결합되어야 합니다. 느슨한 결합은 한 컨텍스트의 요구 사항 변경이 종속 변경의 급증을 인접 컨텍스트에 전파하지 않도록 보장할 수 있습니다.
도메인 모델 및 제한된 컨텍스트 활용
모든 조직은 자신과 외부 세계 사이에 단일 도메인을 형성합니다. 조직 내에서 일하는 모든 사람은 해당 도메인의 요구 사항을 지원하기 위해 운영됩니다.
이 도메인은 기술 중심 회사, 엔지니어링 부서, 영업 부서 및 고객 지원 부서 등의 하위 도메인으로 분류됩니다. 각 하위 도메인에는 고유한 요구 사항과 의무가 있으며 자체적으로 세분화될 수 있습니다. 이 분할 프로세스는 하위 도메인 모델이 세분화되고 실행 가능하며 구현 팀에 의해 작고 독립적인 서비스로 변환될 수 있을 때까지 반복됩니다. 제한된 컨텍스트는 이러한 하위 도메인을 중심으로 설정되며 마이크로서비스 생성을 위한 기반을 형성합니다.
제한된 컨텍스트를 비즈니스 요구 사항에 맞게 조정
조직의 변화나 새로운 기능 요청으로 인해 제품 수명 동안 제품의 비즈니스 요구 사항이 변경되는 것이 일반적입니다. 대조적으로, 회사가 비즈니스 요구 사항 변경을 수반하지 않고 특정 제품의 기본 구현을 변경해야 하는 경우는 거의 없습니다. 이것이 바로 제한된 컨텍스트가 기술적 요구 사항이 아닌 비즈니스 요구 사항을 중심으로 구축되어야 하는 이유입니다.
비즈니스 요구 사항에 대한 제한된 컨텍스트를 조정하면 팀은 느슨하게 결합되고 응집력이 뛰어난 방식으로 마이크로서비스 구현을 변경할 수 있습니다.이는 특정 비즈니스 요구 사항에 대한 솔루션을 설계하고 구현할 수 있는 자율성을 팀에 제공하여 팀 간 종속성을 크게 줄이고 각 팀이 자신의 요구 사항에만 집중할 수 있도록 합니다.
반대로, 기술 요구 사항에 따라 마이크로서비스를 조정하는 것은 문제가 있습니다. 이 패턴은 부적절하게 설계된 동기식 지점 간 마이크로서비스와 팀이 애플리케이션의 특정 기술 계층을 소유하는 기존의 모놀리식 스타일 컴퓨팅 시스템에서 흔히 볼 수 있습니다. 기술 조정의 주요 문제는 다양한 일정과 임무를 가진 여러 팀이 포함될 수 있는 여러 제한된 컨텍스트에 걸쳐 비즈니스 기능을 수행하는 책임을 분산한다는 것입니다. 어떤 팀도 솔루션 구현을 단독으로 담당하지 않기 때문에 각 서비스는 팀과 API 경계를 넘어 다른 서비스와 결합되어 변경이 어렵고 비용이 많이 듭니다. 겉으로는 무해해 보이는 변경, 버그 또는 실패한 서비스는 기술 시스템을 사용하는 모든 서비스의 비즈니스 지원 기능에 심각한 파급 효과를 미칠 수 있습니다. 기술 정렬은 EDM(이벤트 중심 마이크로서비스) 아키텍처에서는 거의 사용되지 않으며 가능하면 완전히 피해야 합니다.교차 기술 및 팀 종속성을 제거하면 변경에 대한 시스템의 민감도가 줄어듭니다.
그림 1-2는 두 가지 시나리오를 모두 보여줍니다. 왼쪽은 단독 소유권이고 오른쪽은 교차 소유권입니다. 단독 소유권을 가진 팀은 두 가지 독립적인 비즈니스 요구 사항(제한된 컨텍스트)을 중심으로 완전히 구성되어 있으며 애플리케이션 코드와 데이터베이스 계층을 완벽하게 제어합니다. 오른쪽의 팀은 기술 요구 사항을 통해 구성되었으며, 여기서 애플리케이션 계층은 데이터 계층과 별도로 관리됩니다. 이는 팀 간에 명시적인 종속성을 생성할 뿐만 아니라 비즈니스 요구 사항 간에 암시적인 종속성을 생성합니다.
비즈니스 요구 사항을 중심으로 이벤트 기반 마이크로서비스 아키텍처를 모델링하는 것이 선호되지만 이 접근 방식에는 장단점이 있습니다. 코드는 여러 번 복제될 수 있으며 많은 서비스가 유사한 데이터 액세스 패턴을 사용할 수 있습니다. 제품 개발자는 데이터 소스를 다른 제품과 공유하거나 경계를 결합하여 반복을 줄이려고 노력할 수 있습니다.이러한 경우 후속 긴밀한 결합은 논리를 반복하고 유사한 데이터를 저장하는 것보다 장기적으로 훨씬 더 많은 비용이 들 수 있습니다. 이러한 장단점은 이 책 전반에 걸쳐 더 자세히 검토될 것입니다.
제한된 컨텍스트 간의 느슨한 결합을 유지하고 컨텍스트 간 종속성을 최소화하는 데 중점을 둡니다. 이를 통해 나중에 많은(또는 모든) 다른 시스템을 중단하지 않고 필요에 따라 제한된 컨텍스트 구현을 변경할 수 있습니다.
또한 각 팀은 전체 스택 전문 지식을 보유해야 할 수 있으며 이는 전문 기술 세트 및 액세스 권한의 필요성으로 인해 복잡해질 수 있습니다. 조직은 이러한 수직적 팀이 스스로를 지원할 수 있도록 가장 일반적인 요구 사항을 운영화하는 동시에 필요에 따라 팀 간에서 보다 전문적인 기술 세트를 제공할 수 있어야 합니다. 이러한 모범 사례는 14장 에서 자세히 다룹니다 .
통신 구조
조직의 팀, 시스템, 사람은 모두 목표를 달성하기 위해 서로 소통해야 합니다. 이러한 통신은 통신 구조 라고 하는 종속성의 상호 연결된 토폴로지를 형성합니다 . 세 가지 주요 통신 구조가 있으며 각 구조는 비즈니스 운영 방식에 영향을 미칩니다.
비즈니스 커뮤니케이션 구조
비즈니스 커뮤니케이션 구조( 그림 1-3 )는 각 팀과 부서에 할당된 주요 요구 사항과 책임에 따라 이루어지는 커뮤니케이션을 규정합니다. 예를 들어 엔지니어링은 소프트웨어 제품을 생산하고, 영업은 고객에게 판매하며, 지원은 고객과 클라이언트의 만족을 보장합니다. 주요 비즈니스 단위부터 개별 기여자의 작업에 이르기까지 팀 구성과 목표 제공이 이 구조에 속합니다. 비즈니스 요구 사항, 팀에 대한 할당, 팀 구성은 모두 시간이 지남에 따라 변경되며, 이는 비즈니스 커뮤니케이션 구조와 구현 커뮤니케이션 구조 간의 관계에 큰 영향을 미칠 수 있습니다.
구현 통신 구조
구현 통신 구조 ( 그림 1-4 )는 조직에서 지시한 대로 하위 도메인 모델과 관련된 데이터 및 논리입니다. 비즈니스 운영이 빠르고 효율적으로 수행될 수 있도록 비즈니스 프로세스, 데이터 구조 및 시스템 설계를 공식화합니다. 구현에 의해 충족되어야 하는 비즈니스 요구 사항을 재정의하려면 논리를 다시 작성해야 하므로 이로 인해 비즈니스 통신 구조의 유연성이 저하됩니다. 이러한 재작성은 하위 도메인 모델 및 관련 코드에 대한 반복적인 수정인 경우가 가장 많으며, 시간이 지남에 따라 새로운 비즈니스 요구 사항을 충족하기 위한 구현의 발전을 반영합니다.
소프트웨어 엔지니어링을 위한 구현 통신 구조의 전형적인 예는 모놀리식 데이터베이스 애플리케이션입니다. 애플리케이션의 비즈니스 로직은 함수 호출이나 공유 상태를 통해 내부적으로 통신합니다. 이 모놀리식 애플리케이션은 비즈니스 커뮤니케이션 구조에 따른 비즈니스 요구 사항을 충족하는 데 사용됩니다.
데이터 통신 구조
데이터 통신 구조( 그림 1-5 )는 비즈니스 전체, 특히 구현 간에 데이터가 통신되는 프로세스입니다. 이메일, 인스턴트 메시징, 회의로 구성된 데이터 통신 구조는 비즈니스 변화를 전달하는 데 종종 사용되지만 소프트웨어 구현에서는 대체로 무시되어 왔습니다. 그 역할은 일반적으로 시스템에서 시스템으로 즉석에서 수행되었으며, 구현 통신 구조는 자체 요구 사항 외에 데이터 통신 기능을 포함하여 이중 임무를 수행하는 경우가 많습니다. 이로 인해 시간이 지남에 따라 기업이 성장하고 변화하는 방식에 많은 문제가 발생했으며, 그 영향은 다음 섹션에서 평가됩니다.
콘웨이의 법칙과 의사소통 구조
시스템을 디자인하는 조직은...이 조직의 커뮤니케이션 구조를 복사한 디자인을 생산하도록 제약을 받습니다.
멜빈 콘웨이 - 위원회는 어떻게 발명하는가? (1968년 4월)
콘웨이의 법칙 으로 알려진 이 인용문은 팀이 조직의 커뮤니케이션 구조에 따라 제품을 구축한다는 것을 의미합니다. 비즈니스 커뮤니케이션 구조는 사람들을 팀으로 구성하며, 이러한 팀은 일반적으로 팀 경계로 구분되는 제품을 생산합니다. 구현 통신 구조는 특정 제품에 대한 하위 도메인 데이터 모델에 대한 액세스를 제공하지만 약한 데이터 통신 기능으로 인해 다른 제품에 대한 액세스도 제한합니다.
도메인 개념은 비즈니스 전반에 걸쳐 있기 때문에 조직 내 다른 제한된 컨텍스트에서 도메인 데이터가 필요한 경우가 많습니다. 구현 통신 구조는 일반적으로 이러한 통신 메커니즘을 제공하는 데는 열악하지만 제한된 컨텍스트의 요구 사항을 제공하는 데는 뛰어납니다. 이는 두 가지 방식으로 제품 디자인에 영향을 미칩니다. 첫째, 필요한 도메인 데이터를 조직 전체에 전달하는 비효율성으로 인해 논리적으로 분리된 새로운 제품의 생성을 방해합니다. 둘째, 새로운 비즈니스 요구 사항을 수용하기 위해 도메인을 지속적으로 확장할 위험이 있지만 기존 도메인 데이터에 쉽게 액세스할 수 있습니다. 이 특별한 패턴은 모놀리식 디자인으로 구현됩니다.
데이터 통신 구조는 조직이 제품을 설계하고 구축하는 방식에서 중추적인 역할을 하지만 많은 조직에서는 이 구조가 오랫동안 누락되었습니다. 언급한 바와 같이 구현 통신 구조는 자신의 역할 외에 이 역할을 수행하는 경우가 많습니다.
일부 조직은 다른 구현에서 도메인 데이터에 액세스할 수 없는 문제를 완화하려고 시도하지만 이러한 노력에는 고유한 단점이 있습니다.예를 들어 공유 데이터베이스가 자주 사용되지만 이러한 데이터베이스는 안티 패턴을 촉진하는 경우가 많으며 모든 성능 요구 사항을 수용할 만큼 충분히 확장할 수 없는 경우가 많습니다. 데이터베이스는 읽기 전용 복제본을 제공할 수 있습니다. 그러나 이로 인해 내부 데이터 모델이 불필요하게 노출될 수 있습니다. 일괄 처리 프로세스는 다른 프로세스에서 읽을 수 있도록 데이터를 파일 저장소에 덤프할 수 있지만 이 접근 방식은 데이터 일관성 및 여러 정보 소스와 관련된 문제를 일으킬 수 있습니다. 마지막으로, 이러한 모든 솔루션은 구현 간의 강력한 결합을 가져오고 아키텍처를 직접적인 지점 간 관계 로 더욱 강화합니다 .
조직의 데이터에 액세스하기가 너무 어렵거나 모든 데이터가 단일 구현에 위치하기 때문에 제품의 범위가 확장되는 경우 열악한 데이터 통신 구조의 영향을 경험할 가능성이 높습니다. 이 문제는 조직이 성장하고, 새로운 제품을 개발하고, 일반적으로 사용되는 도메인 데이터에 대한 액세스 필요성이 점점 더 커짐에 따라 더욱 확대될 것입니다.
기존 컴퓨팅의 통신 구조
조직의 커뮤니케이션 구조는 엔지니어링 구현이 생성되는 방식에 큰 영향을 미칩니다. 이는 팀 수준에서도 마찬가지입니다. 팀의 커뮤니케이션 구조는 팀에 할당된 특정 비즈니스 요구 사항에 맞게 구축하는 솔루션에 영향을 미칩니다. 이것이 실제로 어떻게 작동하는지 살펴보겠습니다.
다음 시나리오를 고려해보세요. 단일 팀에는 단일 데이터 저장소가 지원하는 단일 서비스가 있습니다. 그들은 행복하게 비즈니스 기능을 제공하고 있으며 모든 것이 잘되고 있습니다. 어느 날 팀 리더가 새로운 비즈니스 요구 사항을 가지고 왔습니다. 이는 팀이 이미 수행하고 있는 작업과 다소 관련이 있으며 기존 서비스에 추가될 수도 있습니다. 그러나 자체적인 새로운 서비스에 들어갈 수 있을 만큼 충분히 다릅니다.
팀은 기로에 서 있습니다. 새 서비스에 새로운 비즈니스 요구 사항을 구현해야 할까요, 아니면 단순히 기존 서비스에 추가해야 할까요? 옵션을 좀 더 자세히 살펴보겠습니다.
옵션 1: 새 서비스 만들기
비즈니스 요구사항은 충분히 다르기 때문에 이를 새로운 서비스에 적용하는 것이 타당할 수 있습니다. 하지만 데이터는 어떻습니까? 이 새로운 비즈니스 기능에는 이전 데이터 중 일부가 필요하지만 해당 데이터는 현재 기존 서비스에 잠겨 있습니다. 또한 팀에는 완전히 독립적인 새 서비스를 출시하기 위한 프로세스가 실제로 없습니다. 반면에 팀은 점점 커지고 회사는 빠르게 성장하고 있습니다. 나중에 팀을 나누어야 하는 경우 모듈식 및 독립형 시스템을 사용하면 소유권을 훨씬 쉽게 분배할 수 있습니다.
이 접근 방식과 관련된 위험이 있습니다. 팀은 원래 데이터 저장소에서 데이터를 소싱하고 이를 새 데이터 저장소에 복사하는 방법을 찾아야 합니다. 그들은 내부 작업을 노출하지 않고 데이터 구조에 대한 변경 사항이 데이터를 복사하는 다른 팀에 영향을 미치지 않도록 해야 합니다. 또한 쿼리로 인해 데이터 저장소가 포화되지 않도록 30분마다 실시간으로 프로덕션 데이터만 복사할 수 있으므로 복사되는 데이터는 항상 다소 오래된 것입니다. 이 연결이 올바르게 실행되고 있는지 확인하기 위해 모니터링하고 유지 관리해야 합니다.
새로운 서비스를 시작하고 실행하는 데에도 위험이 있습니다. 두 개의 데이터 저장소와 두 개의 서비스를 관리하고 이에 대한 로깅, 모니터링, 테스트, 배포 및 롤백 프로세스를 설정해야 합니다. 또한 종속 시스템에 영향을 주지 않도록 데이터 구조 변경 사항을 동기화하도록 주의해야 합니다.
옵션 2: 기존 서비스에 추가
다른 옵션은 기존 서비스 내에 새로운 데이터 구조와 비즈니스 로직을 생성하는 것입니다. 필요한 데이터는 이미 데이터 저장소에 있으며 로깅, 모니터링, 테스트, 배포 및 롤백 프로세스가 이미 정의되어 사용 중입니다. 팀은 시스템에 익숙하고 로직 구현 작업을 바로 시작할 수 있으며, 모놀리식 패턴은 서비스 디자인에 대한 이러한 접근 방식을 지원합니다.
이 접근 방식과 관련된 위험도 있지만 좀 더 미묘합니다. 변경 사항이 발생하면 구현 내의 경계가 흐려질 수 있습니다. 특히 모듈이 동일한 코드베이스에 함께 묶이는 경우가 많기 때문입니다. 이러한 경계를 넘어 기능을 빠르게 추가하고 모듈 전체에 직접 결합하는 것은 너무 쉽습니다.빠르게 움직이면 큰 이점이 있지만 긴밀한 결합, 응집력 감소, 모듈성 부족이라는 대가를 치르게 됩니다. 팀에서는 이를 방지할 수 있지만 탁월한 계획과 엄격한 경계 준수가 필요하며, 이는 빡빡한 일정, 경험 부족, 서비스 소유권 변동으로 인해 종종 방해가 됩니다 .
각 옵션의 장단점
대부분의 팀은 기존 시스템에 기능을 추가하는 두 번째 옵션을 선택합니다. 이 선택에는 아무런 문제가 없습니다. 모놀리식 아키텍처는 유용하고 강력한 구조이며 비즈니스에 탁월한 가치를 제공할 수 있습니다. 첫 번째 옵션은 기존 컴퓨팅과 관련된 두 가지 문제를 먼저 해결합니다.
- 다른 시스템의 데이터에 안정적으로 액세스하는 것은 특히 대규모로 실시간으로 수행하기 어렵습니다.
- 새로운 서비스를 만들고 관리하는 것은 상당한 오버헤드와 그에 따른 위험을 안겨줍니다. 특히 조직 내에서 그렇게 할 수 있는 확립된 방법이 없는 경우에는 더욱 그렇습니다.
로컬 데이터에 액세스하는 것은 다른 데이터 저장소에 있는 데이터에 액세스하는 것보다 항상 쉽습니다. 다른 팀의 데이터 저장소에 캡슐화된 데이터는 구현 및 비즈니스 커뮤니케이션 경계를 모두 넘어야 하므로 얻기가 어렵습니다. 데이터, 연결 수 및 성능 요구 사항이 증가함에 따라 유지 관리 및 확장이 점점 더 어려워지고 있습니다.
필요한 데이터를 복사하는 것은 가치 있는 접근 방식이지만 완벽한 방법은 아닙니다. 이 모델은 조직이 성장하고, 사업부와 소유권이 변경되고, 제품이 성숙되고 단계적으로 폐지됨에 따라 유지 관리가 문제가 되는 많은 직접적인 지점 간 결합을 장려합니다. 이는 두 팀(데이터를 저장하는 팀과 이를 복사하는 팀)의 구현 통신 구조에 엄격한 기술적 종속성을 생성하므로 데이터가 변경될 때마다 두 팀이 동시에 작업해야 합니다. 다른 시스템이 여기에 긴밀하게 연결되지 않도록 구현의 내부 데이터 모델이 과도하게 노출되지 않도록 특별한 주의를 기울여야 합니다. 데이터 복제 쿼리로 인해 소스 시스템에 지속 불가능한 로드가 발생할 수 있으므로 확장성, 성능 및 시스템 가용성은 두 시스템 모두에서 문제가 되는 경우가 많습니다. 실패한 동기화 프로세스는 긴급 상황이 발생할 때까지 발견되지 않을 수 있습니다. 부족 지식으로 인해 팀은 데이터 사본을 복사하여 그것이 원본 진실의 소스라고 생각하게 될 수 있습니다.
복사된 데이터는 쿼리가 완료되고 데이터가 전송될 때쯤에는 항상 다소 오래된 상태가 됩니다. 데이터 세트가 크고 소스가 복잡할수록 복사본이 원본과 동기화되지 않을 가능성이 높아집니다. 이는 시스템이 서로 완벽한 최신 복사본을 가질 것으로 기대하는 경우, 특히 해당 데이터에 대해 서로 통신할 때 문제가 됩니다. 예를 들어 보고 서비스는 부실로 인해 청구 서비스와 다른 값을 보고할 수 있습니다. 이는 서비스 품질, 보고, 분석 및 금전 기반 의사 결정에 심각한 결과를 초래할 수 있습니다.
회사 전체에 데이터를 올바르게 전파할 수 없는 것은 개념의 근본적인 결함 때문이 아닙니다. 오히려 그 반대입니다. 데이터 통신 구조가 약하거나 존재하지 않기 때문입니다. 이전 시나리오에서 팀의 구현 통신 구조는 극도로 제한된 데이터 통신 구조로서 이중 임무를 수행합니다.
이벤트 중심 마이크로서비스의 원칙 중 하나는 핵심 비즈니스 데이터를 필요한 모든 서비스에서 쉽게 얻고 사용할 수 있어야 한다는 것입니다. 이는 이 시나리오의 임시 데이터 통신 구조를 공식화된 데이터 통신 구조로 대체합니다. 가상 팀의 경우 이 데이터 통신 구조는 다른 시스템에서 데이터를 얻는 데 따른 어려움을 대부분 제거할 수 있습니다.
팀 시나리오(계속)
1년을 앞당겨 보세요. 팀은 옵션 2를 선택하고 동일한 서비스 내에 새로운 기능을 통합하기로 결정했습니다. 빠르고 쉬웠으며 그 이후로 여러 가지 새로운 기능을 구현했습니다. 회사가 성장하면서 팀도 성장했고, 이제는 더 작고 집중적인 두 팀으로 개편해야 할 때입니다.
이제 각 새 팀에는 이전 서비스의 특정 비즈니스 기능이 할당되어야 합니다. 각 팀의 비즈니스 요구사항은 가장 주의가 필요한 비즈니스 영역을 기준으로 깔끔하게 구분되어 있습니다. 그러나 구현 통신 구조를 분할하는 것은 쉬운 일이 아닙니다. 이전과 마찬가지로 두 팀 모두 요구 사항을 충족하기 위해 동일한 데이터가 대량으로 필요한 것 같습니다. 새로운 질문이 제기됩니다.
- 어느 팀이 어떤 데이터를 소유해야 할까요?
- 데이터는 어디에 상주해야 합니까?
- 두 팀 모두 값을 수정해야 하는 데이터는 어떻습니까?
팀 리더는 대신 서비스를 공유하는 것이 가장 좋을 수 있으며 두 사람 모두 서로 다른 부분을 작업할 수 있다고 결정합니다. 이를 위해서는 훨씬 더 많은 팀 간 커뮤니케이션과 노력 동기화가 필요하며, 이는 생산성을 저하시킬 수 있습니다. 그리고 미래에 크기가 다시 두 배로 커진다면 어떨까요? 아니면 비즈니스 요구 사항이 충분히 변경되어 더 이상 동일한 데이터 구조로 모든 것을 충족할 수 없는 경우에는 어떻게 될까요?
상충되는 압력
원래 팀에는 두 가지 상충되는 압력이 있습니다. 구현 통신 구조를 확장하는 대신 새로운 비즈니스 기능을 더 빠르고 쉽게 추가하기 위해 모든 데이터를 하나의 서비스에 로컬로 유지하는 데 영향을 받았습니다. 결국 팀의 성장으로 인해 비즈니스 커뮤니케이션 구조가 분리되어야 했으며, 이에 따라 비즈니스 요구 사항이 새 팀에 재할당되었습니다. 그러나 구현 통신 구조는 현재 형식으로는 재할당을 지원할 수 없으며 적절한 구성 요소로 분해되어야 합니다. 두 접근 방식 모두 확장 가능하지 않으며 둘 다 작업을 다르게 수행해야 한다는 점을 지적합니다. 이러한 문제는 모두 동일한 근본 원인, 즉 구현 통신 구조 간에 데이터를 통신하는 약하고 잘못 정의된 수단에서 비롯됩니다.
이벤트 기반 통신 구조
이벤트 중심 접근 방식은 기존 구현 동작 및 데이터 통신 구조에 대한 대안을 제공합니다. 이벤트 기반 통신은 요청-응답 통신을 즉시 대체하는 것이 아니라 완전히 다른 서비스 간 통신 방식입니다. 이벤트 스트리밍 데이터 통신 구조는 데이터 생산 및 소유권과 이에 대한 액세스를 분리합니다. 서비스는 더 이상 요청-응답 API를 통해 직접 연결되지 않고 대신 이벤트 스트림 내에 정의된 이벤트 데이터를 통해 연결됩니다(이 프로세스는 3장 에서 자세히 다룹니다 ).생산자의 책임은 각각의 이벤트 스트림에 잘 정의된 데이터를 생성하는 것으로 제한됩니다.
이벤트는 의사소통의 기초입니다
공유 가능한 모든 데이터는 일련의 이벤트 스트림에 게시되어 조직에서 발생한 모든 일을 자세히 설명하는 연속적이고 표준적인 내러티브를 형성합니다. 이는 시스템이 서로 통신하는 채널이 됩니다. 단순한 발생부터 복잡한 상태 저장 기록까지 거의 모든 것이 이벤트로 전달될 수 있습니다. 이벤트 는 데이터 입니다 . 이는 단순히 데이터가 다른 곳에서 준비되었음을 나타내는 신호이거나 한 구현에서 다른 구현으로 직접 데이터를 전송하는 수단이 아닙니다. 오히려 데이터 저장소 역할과 서비스 간 비동기 통신 수단 역할을 모두 수행합니다.
이벤트 스트림은 단일 정보 소스를 제공합니다.
스트림의 각 이벤트는 사실에 대한 진술이며 이러한 진술이 함께 단일 진실 소스, 즉 조직 내 모든 시스템에 대한 통신의 기초를 형성합니다. 커뮤니케이션 구조는 정보의 진실성만큼 중요하므로 조직이 이벤트 스트림 내러티브를 단일 진실 소스로 채택하는 것이 중요합니다. 일부 팀이 충돌하는 데이터를 다른 위치에 배치하기로 선택한 경우 조직의 데이터 통신 백본인 이벤트 스트림의 기능이 크게 저하됩니다.
소비자는 자신의 모델링 및 쿼리를 수행합니다.
이벤트 기반 데이터 통신 구조는 쿼리 또는 데이터 조회 기능을 제공할 수 없다는 점에서 과도하게 확장된 구현 통신 구조와 다릅니다.모든 비즈니스 및 애플리케이션 논리는 이벤트의 생산자와 소비자 내에 캡슐화되어야 합니다.
데이터 액세스 및 모델링 요구 사항은 소비자에게 완전히 이전되었으며 소비자는 각각 소스 이벤트 스트림에서 자신의 이벤트 복사본을 얻습니다. 쿼리 복잡성도 데이터 소유자의 구현 통신 구조에서 소비자의 구현 통신 구조로 전환됩니다. 소비자는 여러 이벤트 스트림의 데이터 혼합, 특수 쿼리 기능 또는 기타 비즈니스별 구현 논리에 대해 전적인 책임을 집니다. 생산자와 소비자 모두 쿼리 메커니즘, 데이터 전송 메커니즘, API(응용 프로그래밍 인터페이스) 및 데이터 통신 수단을 위한 팀 간 서비스를 제공할 의무가 면제됩니다. 이제 그들은 즉각적인 제한된 컨텍스트의 요구 사항을 해결하는 것으로만 책임이 제한됩니다.
조직 전반에 걸쳐 데이터 통신이 향상됩니다.
데이터 통신 구조의 사용은 모든 공유 가능한 데이터가 구현 통신 구조 외부에 노출되는 반전입니다. 모든 데이터를 공유해야 하는 것은 아니므로 모든 데이터를 이벤트 스트림 세트에 게시할 필요는 없습니다. 그러나 다른 팀이나 서비스에 관심이 있는 모든 데이터는 공통 이벤트 스트림 세트에 게시되어야 데이터의 생산과 소유권이 완전히 분리됩니다. 이는 오랫동안 시스템 아키텍처에서 누락된 형식화된 데이터 통신 구조를 제공하고 느슨한 결합 및 높은 응집성의 제한된 컨텍스트 원칙을 더 잘 준수합니다.
이제 응용 프로그램은 지점 간 연결을 통해 얻기가 어려웠던 데이터에 액세스할 수 있습니다. 새로운 서비스는 다른 서비스와의 직접적인 지점 간 연결이나 API에 의존하지 않고 표준 이벤트 스트림에서 필요한 데이터를 획득하고, 자체 모델과 상태를 생성하고, 필요한 비즈니스 기능을 수행할 수 있습니다. 이를 통해 조직은 모든 제품에서 방대한 양의 데이터를 보다 효과적으로 사용할 수 있으며, 고유하고 강력한 방식으로 여러 제품의 데이터를 혼합할 수도 있습니다.
접근 가능한 데이터는 비즈니스 커뮤니케이션 변화를 지원합니다.
이벤트 스트림에는 비즈니스 운영의 중심이 되는 핵심 도메인 이벤트가 포함되어 있습니다. 팀이 구조를 조정하고 프로젝트가 왔다 갔다 할 수도 있지만 중요한 핵심 도메인 데이터는 특정 구현 통신 구조와 관계없이 이를 필요로 하는 모든 신제품에서 쉽게 사용할 수 있습니다 . 이는 핵심 도메인 이벤트에 대한 액세스가 더 이상 특정 구현에 의존하지 않기 때문에 비즈니스에 탁월한 유연성을 제공합니다.
비동기식 이벤트 기반 마이크로서비스
이벤트 기반 마이크로서비스는 제한된 컨텍스트의 요구 사항을 충족하는 데 필요한 비즈니스 논리 변환 및 운영을 지원합니다. 이러한 애플리케이션은 이러한 요구 사항을 충족하고 필요한 자체 이벤트를 다른 다운스트림 소비자에게 내보내는 임무를 맡습니다. 이벤트 기반 마이크로서비스를 사용하면 얻을 수 있는 몇 가지 주요 이점은 다음과 같습니다.
세분성서비스는 제한된 컨텍스트에 깔끔하게 매핑되며 비즈니스 요구 사항이 변경되면 쉽게 다시 작성할 수 있습니다.
확장성필요에 따라 개별 서비스를 확장하거나 축소할 수 있습니다.
기술적 유연성서비스는 가장 적절한 언어와 기술을 사용합니다. 또한 선구적인 기술을 사용하여 쉽게 프로토타입을 제작할 수 있습니다.
비즈니스 요구사항 유연성세분화된 마이크로서비스의 소유권은 재구성하기 쉽습니다. 대규모 서비스에 비해 팀 간 종속성이 적고 조직은 데이터 액세스 장벽으로 인해 방해를 받을 수 있는 비즈니스 요구 사항의 변화에 더 신속하게 대응할 수 있습니다.
느슨하게 결합이벤트 기반 마이크로서비스는 특정 구현 API가 아닌 도메인 데이터에 결합됩니다. 데이터 스키마를 사용하면 3장 에서 설명하는 것처럼 데이터 변경 사항을 관리하는 방법을 크게 개선할 수 있습니다 .
지속적인 전달 지원소규모의 모듈식 마이크로서비스를 쉽게 출시하고 필요한 경우 롤백할 수 있습니다.
높은 테스트 가능성마이크로서비스는 대규모 모놀리스보다 종속성이 적은 경향이 있으므로 필요한 테스트 엔드포인트를 더 쉽게 모의하고 적절한 코드 적용 범위를 보장할 수 있습니다 .
이벤트 기반 마이크로서비스를 사용하는 예시 팀
이벤트 기반 데이터 통신 구조를 사용하는 이전 팀을 다시 살펴보겠습니다.
새로운 비즈니스 요구 사항이 팀에 도입되었습니다. 이는 현재 제품이 수행하는 작업과 어느 정도 관련이 있지만 자체 서비스에 들어갈 수 있을 만큼 충분히 다릅니다. 기존 서비스에 추가하면 단일 책임 원칙을 위반하고 현재 정의된 제한된 컨텍스트를 과도하게 확장합니까? 아니면 기존 서비스에 새로운 관련 데이터나 기능을 추가하는 단순한 확장인가요?
데이터 소스 위치 및 싱크 방법 파악, 일괄 동기화 문제 처리, 동기 API 구현 등 이전의 기술 문제는 이제 대부분 제거되었습니다. 팀은 필요한 경우 새로운 마이크로서비스를 가동하고 이벤트 스트림에서 필요한 데이터를 처음부터 다시 수집할 수 있습니다. 해당 데이터가 새로운 제한된 컨텍스트의 요구 사항을 충족하는 데에만 사용되는 한 팀에서 다른 서비스에 사용되는 공통 데이터를 혼합하는 것은 전적으로 가능합니다. 이 데이터의 저장 및 구조는 전적으로 팀에 달려 있으며, 유지할 필드와 삭제할 필드를 선택할 수 있습니다.
작고 세분화된 서비스를 통해 단일 팀 소유권을 허용하고 필요에 따라 팀을 확장하고 재구성할 수 있으므로 비즈니스 위험도 완화됩니다. 팀이 단일 비즈니스 소유자로 관리하기에는 너무 커지면 필요에 따라 팀을 분할하고 마이크로서비스 소유권을 재할당할 수 있습니다. 이벤트 데이터의 소유권은 생산 서비스와 함께 이동하며, 향후 작업을 수행하는 데 필요한 팀 간 커뮤니케이션 양을 줄이기 위해 조직의 결정을 내릴 수 있습니다.
새로운 서비스를 생성하고 필요한 데이터를 얻기 위한 오버헤드가 최소화된다면 마이크로서비스의 특성으로 인해 스파게티 코드와 광범위한 모놀리스가 유지되는 것이 방지됩니다. 이제 확장 문제는 필요에 따라 CPU, 메모리, 디스크 및 인스턴스 수를 확장할 수 있는 개별 이벤트 처리 서비스에 집중됩니다. 나머지 확장 요구 사항은 데이터 통신 구조로 오프로드되어 이벤트 스트림을 소비하고 생성하는 다양한 서비스 로드를 처리할 수 있도록 보장해야 합니다.
그러나 이 모든 작업을 수행하려면 팀은 데이터가 데이터 통신 구조에 실제로 존재하는지 확인해야 하며, 마이크로서비스 플릿을 쉽게 가동하고 관리할 수 있는 수단이 있어야 합니다. 이를 위해서는 조직 전반에 걸쳐 EDM 아키텍처를 채택해야 합니다.
동기식 마이크로서비스
마이크로서비스는 이벤트(이 책에서 옹호하는 접근 방식)를 사용하여 비동기적으로 구현되거나 서비스 지향 아키텍처에서 일반적인 동기적으로 구현될 수 있습니다. 동기식 마이크로서비스는 서비스가 비즈니스 요구 사항을 충족하기 위해 API를 통해 직접 통신하는 요청-응답 접근 방식을 사용하여 이행되는 경향이 있습니다.
동기식 마이크로서비스의 단점
동기식 마이크로서비스에는 대규모로 사용하기 어렵게 만드는 여러 가지 문제가 있습니다. 이는 Netflix, Lyft, Uber, Facebook과 같은 기업의 성과에서 알 수 있듯이 동기식 마이크로서비스를 사용하여 기업이 성공할 수 없다는 의미는 아닙니다. 그러나 많은 회사는 구식이고 끔찍하게 얽힌 스파게티 코드 단일체를 사용하여 부를 얻었으므로 회사의 궁극적인 성공과 기본 아키텍처의 품질을 혼동하지 마십시오. 동기식 마이크로서비스를 구현하는 방법을 설명하는 책이 많이 있으므로 동기식 접근 방식을 더 잘 이해하려면 해당 책을 읽어 보는 것이 좋습니다. 1
또한 지점 간 요청-응답 마이크로서비스나 비동기 이벤트 기반 마이크로서비스 중 어느 것도 다른 것보다 엄격하게 우수하지는 않습니다. 일부 작업은 다른 작업보다 훨씬 더 적합하기 때문에 둘 다 조직에서 자신의 위치를 가집니다. 그러나 내 경험과 많은 동료 및 동료의 경험에 따르면 EDM 아키텍처는 동기식 요청-응답 마이크로서비스에는 없는 비교할 수 없는 유연성을 제공합니다. 아마도 이 책을 읽으면서 동의하게 되겠지만, 최소한 그 책들의 장점과 단점을 이해하게 될 것입니다.
동기식 요청-응답 마이크로서비스의 가장 큰 단점은 다음과 같습니다.
지점간 커플링
동기식 마이크로서비스는 다른 서비스를 사용하여 비즈니스 작업을 수행하는 데 도움을 줍니다. 이러한 서비스에는 자체 종속 서비스가 있으며, 이러한 서비스에는 자체 종속 서비스 등이 있습니다. 이로 인해 과도한 팬아웃이 발생하고 어떤 서비스가 비즈니스 로직의 특정 부분을 이행하는지 추적하기가 어려워질 수 있습니다. 서비스 간 연결 수가 엄청나게 많아지면 기존 통신 구조가 더욱 견고해지고 향후 변화가 더욱 어려워질 수 있습니다.
종속적 확장
자체 서비스를 확장하는 능력은 모든 종속 서비스의 확장 능력에 따라 달라지며 통신 팬아웃 정도와 직접적인 관련이 있습니다. 구현 기술은 확장성에 병목 현상을 일으킬 수 있습니다. 이는 전체 아키텍처에서 모두 동기식으로 처리되어야 하는 매우 가변적인 로드와 급증하는 요청 패턴으로 인해 더욱 복잡해집니다.
서비스 장애 처리
종속 서비스가 중단되면 예외 처리 방법을 결정해야 합니다. 중단 처리 방법, 재시도 시기, 실패 시기 및 데이터 일관성을 보장하기 위한 복구 방법을 결정하는 것은 생태계 내에 서비스가 많아질수록 점점 더 어려워집니다.
API 버전 관리 및 종속성 관리
여러 API 정의와 서비스 버전이 동시에 존재해야 하는 경우가 많습니다. 클라이언트가 최신 API로 업그레이드하도록 강제하는 것이 항상 가능하거나 바람직한 것은 아닙니다. 이로 인해 여러 서비스에 걸쳐 API 변경 요청을 조정하는 데 많은 복잡성이 추가될 수 있으며, 특히 기본 데이터 구조에 대한 변경이 수반되는 경우 더욱 그렇습니다.
구현과 관련된 데이터 액세스
동기식 마이크로서비스는 외부 데이터에 액세스할 때 기존 서비스와 동일한 문제를 안고 있습니다. 외부 데이터에 액세스해야 하는 필요성을 완화하기 위한 서비스 설계 전략이 있지만 마이크로서비스는 여전히 다른 서비스에서 일반적으로 사용되는 데이터에 액세스해야 하는 경우가 많습니다. 이는 구현 통신 구조에 데이터 액세스 및 확장성의 부담을 다시 부여합니다.
분산형 모놀리스
서비스는 분산된 단일체 역할을 하도록 구성될 수 있으며 서비스 간에 서로 얽힌 호출이 많이 발생합니다. 이러한 상황은 팀이 모놀리스를 분해하고 동기식 지점 간 호출을 사용하여 모놀리스 내의 기존 경계를 모방하기로 결정할 때 종종 발생합니다. 지점 간 서비스를 사용하면 원격 시스템에 대한 함수 호출이 기존 모놀리스 코드와 한 줄씩 배치될 수 있으므로 제한된 컨텍스트 간의 경계를 쉽게 모호하게 만들 수 있습니다.
테스트
각 서비스에는 완전한 운영 종속성이 필요하고 차례로 자체 서비스가 필요하므로 통합 테스트가 어려울 수 있습니다. 이를 제거하는 것은 단위 테스트에서는 작동할 수 있지만 더 광범위한 테스트 요구 사항에는 충분하지 않은 것으로 입증되었습니다.
동기식 마이크로서비스의 이점
동기식 마이크로서비스가 제공하는 부인할 수 없는 이점이 많이 있습니다. 특정 데이터 액세스 패턴은 사용자 인증 및 AB 테스트 보고와 같은 직접적인 요청-응답 결합에 유리합니다. 외부 타사 솔루션과의 통합은 거의 항상 동기식 메커니즘을 사용하며 일반적으로 HTTP를 통해 유연하고 언어에 구애받지 않는 통신 메커니즘을 제공합니다.
여러 시스템에 걸쳐 작업을 추적하는 것은 비동기 환경보다 동기 환경에서 더 쉬울 수 있습니다. 자세한 로그를 통해 어떤 시스템에서 어떤 기능이 호출되었는지 확인할 수 있어 높은 디버그 가능성과 비즈니스 운영 가시성을 확보할 수 있습니다.
웹 및 모바일 경험을 호스팅하는 서비스는 동기식 또는 비동기식 특성에 관계없이 대체로 요청-응답 설계에 의해 구동됩니다. 고객은 전적으로 자신의 요구에 맞는 시기적절한 응답을 받습니다.
경험 요소도 매우 중요합니다. 특히 오늘날 시장의 많은 개발자가 동기식 모놀리식 스타일 코딩에 훨씬 더 많은 경험을 갖고 있는 경향이 있기 때문입니다. 이는 일반적으로 비동기 이벤트 중심 개발을 위한 인재 확보보다 동기 시스템 인재 확보를 더 쉽게 만듭니다.
회사의 아키텍처가 전적으로 이벤트 중심 마이크로서비스를 기반으로 하는 경우는 거의 없습니다.문제 공간이 요구하는 대로 동기식 및 비동기식 솔루션이 나란히 배포되는 하이브리드 아키텍처가 표준이 될 것입니다.
요약
의사소통 구조는 조직의 수명 전반에 걸쳐 소프트웨어가 어떻게 생성되고 관리되는지를 지시합니다. 데이터 통신 구조는 미개발되고 임시적인 경우가 많지만, 이벤트 중심 시스템으로 구현된 내구성 있고 액세스하기 쉬운 도메인 이벤트 세트를 도입하면 더 작고 특수 목적으로 구축된 구현을 사용할 수 있습니다.
1 예를 들어 Sam Newman의 마이크로서비스 구축 (O'Reilly, 2015) 및 Kasun Indrasiri 및 Prabath Siriwardena의 기업용 마이크로서비스 (Apress, 2018)를 참조하십시오 .
