[마이크로서비스 아키텍처 구축] 마이크로서비스 / 진화적 아키텍트 / 서비스 모델링하기

이 글은 "마이크로서비스 아키텍처 구축 (한빛미디어)"을 읽고 정리한 내용입니다.

1장 마이크로서비스

마이크로서비스란 작고 자율적으로 협업하는 서비스를 의미한다.

마이크로서비스란?

• 작고, 한 가지 일을 잘하는 데 주력
• 서비스 간의 분산도를 높이고 서비스 간에 밀접하게 연결되어 생기는 문제점을 줄이기 위해 서비스 사이의 모든 통신은 네트워크 호출을 통해 이루어진다. 이 서비스들은 서로 독립적으로 변경될 수 있어야 하고, 소비자(호출자)를 변경할 필요 없이 독립적으로 배포될 수 있어야 한다.

주요 혜택

기술 이기종성

• 요구되는 성능 수준을 만족하는 데 유리한 다른 기술 스택을 고려할 수도 있다.
• 변환할 데이터를 어떻게 저장할지 결정할 수도 있다.
• 문제가 전혀 없지는 않기에 몇몇 기업은 프로그래밍 언어 선택에 일부 제한을 걸어둔다. (넷플릭스, 트위터)

회복성 (11장)

• 한 시스템의 컴포넌트에 장애가 발생하더라도 그 장애가 전파되지 않는다면 해당 문제를 격리하고 나머지 시스템을 계속 작동시킬 수 있다.
• 마이크로서비스에서는 서비스의 전체 장애를 차단하고 기능을 적절히 저하시키는 시스템을 구축할 수 있다.
• 하지만 네트워크도 머신처럼 장애가 발생할 수 있다.

확장성

• 필요한 서비스만 확장할 수 있다.
• 나머지 서비스를 더 작고 낮은 사양의 하드웨어에서 실행할 수 있다.

배포 용이성 (6장)

• 모놀리식 애플리케이션에서는 한 줄만 수정하더라도 해당 변경을 릴리스하기 위해 전체 애플리케이션을 배포해야 한다. (배포를 자주하기엔 위험하고 느림)
• 마이크로서비스는 나머지 시스템과 독립적으로 신속히 배포할 수 있고 문제가 발생하더라도 손쉽게 개별 서비스만 롤백함으로써 해당 문제를 격리할 수 있다.

조직 부합성 (10장 콘웨이 법칙)

• 아키텍처를 조직 구조에 맞게 더 적절히 정리할 수 있고, 최적의 팀 크기와 생산성을 위해 하나의 코드베이스에서 일하는 인원을 최소화할 수 있다.

조합성 (5장)

• 조합성이 높은 시스템은 고객의 요구사항에 맞춰 다양한 방식으로 선택하고 조립하여 조합할 수 있는 구성 요소를 제공한다.
• 마이크로서비스를 통해 다양한 방법과 목적으로 우리가 제공하는 기능이 소비되도록 할 수 있다.
• 이제 우리는 웹, 네이티브 앱, 모바일 웹, 태블릿 앱이나 웨어러블 장치를 위한 기능들을 함께 엮을 많은 방법을 고민해야 한다.

대체 가능성을 위한 최적화

• 각 서비스가 작은 크기로 이루어져 있다면 더 나은 구현으로 교체하는 비용을 줄일 수 있으며, 심지어 삭제도 쉽게 할 수 있다.

서비스 지향 아키텍처란

• 서비스 지향 아키텍처(SOA)란 각각 기능을 제공하는 여러 서비스가 서로 협업하도록 하는 설계 접근 방식이다.
  • 서비스는 완전히 분리된 운영시스템의 프로세스를 의미한다.
  • 서비스간 통신은 네트워크 호출로 이루어진다.
• 소프트웨어의 재사용성 장려를 목표로 한다.
• SOA이 마주한 문제점들:
  • 통신 프로토콜(예: SOAP), 벤더 미들웨어, 서비스 세분화에 대한 지침 부족, 분리할 시스템 선정에 대한 잘못된 지침
• 실사용을 기반으로 출현한 마이크로 서비스는 SOA에 적합한 시스템과 아키텍처를 더 잘 이해할 수 있게 해준다. 마이크로서비스는 SOA에 대한 특정 접근법으로 보아야 한다.

기타 분해 기술

분해: 팩토링이라고 불리는 분해는 이해하고, 작성하고, 유지하기 쉽도록 복잡한 문제의 시스템을 외부 동작의 변경 없이 부분으로 나누는 것이다.

공유 라이브러리

• 팀과 서비스 간에 기능을 공유하도록 한다.
• 단점 1. 진정한 기술 이기종성을 잃게 된다.
• 단점 2. 시스템 일부를 독립적으로 확장하기 어려워진다.
• 단점 3. 동적 라이브러리를 사용하지 않는한 전체 프로세스를 재배포하지 않고서는 새로운 라이브러리를 배포할 수 없으므로 변경 부분만 격리하여 배포할 수 있는 능력이 떨어진다.
• 단점 4. 시스템 회복력을 보장하는 구조적 안전조치를 취할 명확한 접합부가 부족하다.

모듈

• 일부 언어는 단순한 라이브러리보다 뛰어난 독자적인 모듈 분해 기능을 제공한다. (OSGI)
• 한 프로세스 안의 여러 모듈을 각각 서비스로 분해하더라도 그것의 모든 문제를 해결하지는 않는다.
• 평범한 개발자로서 우리는 모듈을 공유 라이브러리와 동일한 종류의 혜택을 제공하는 것으로 보아야 한다.

은총알은 없다

• 마이크로서비스가 공짜도, 은총알도 아니며, 황금 망치로 오인되는 일이 없어야 한다.
  • 은총알: 복잡한 문제의 단순하고 신속한 해결책
  • 황금 망치: 가진 것이 오직 망치뿐이라면 모든 사물이 못으로 보이듯이, 익숙한 기술과 개념을 여기저기 지나치게 사용하려는 현상에 대한 비유
• 마이크로서비스는 분산 시스템과 연관된 모든 종류의 복잡성을 내포하고 있다.
• 배포, 테스트, 모니터링을 훨씬 더 잘 다루어야 한다.
• 시스템을 확대하고 회복력을 유지하는 방법에 대해 다르게 생각해야 한다.
• 분산 트랜잭션이나 CAP 정리와 같은 것들이 골치 아플 수도 있기에 각오해야 한다.

2장 진화적 아키텍트

마이크로서비스는 수많은 선택의 기회를 제공한다. 예를 들면, 얼마나 다양한 기술을 사용해야 하는가, 각각의 팀이 서로 다른 프로그래밍 이디엄을 어떻게 사용해야 하는가, 서비스를 어떻게 나누고 통합해야 하는가 등에 대한 선택과 결정을 할 수 있다. 변화의 속도가 빨라지고 아키텍처가 수용할 수 있는 환경이 더 유연해지면서 아키텍트의 역할 또한 변화하고 있다.

아키텍트란

• 아키텍트: 우리가 통합된 기술적 비전을 확실히 확보하게 할 책임이 있으며, 고객이 필요로 하는 시스템을 전달하도록 돕고 다른 사람이 해석하고 실핼할 수 있도록 세부 계획을 세우는 사람
• 아키텍트는 구축하는 시스템의 품질 수준이나 동료들의 근무 조건, 변화에 대응하는 조직의 능력에 대해 그 어떤 다른 역할보다 직접적인 영향을 줄 수 있다.

아키텍트에 대한 진화적 관점

• 아키텍트는 처음부터 완벽한 최종 제품을 만들려하기보다는 추가 학습을 통해 적합한 시스템이 생성되고 지속해서 성장할 수 있는 프레임워크를 만드는 데 보탬이 되어야 한다.
• 사용자가 우리 소프트웨어를 사용하는 한 우리는 그에 대응하고 변화해야 한다.
• 아키텍트는 앞으로 발생할 모든 일을 예측할 수 없는 만큼, 모든 사태에 대해 미리 계획하기보다는 과욕을 부리려는 충동을 절제하고 변화를 받아들이도록 해야 한다.
• 아키텍트는 방향 자체는 개괄적으로 설정하되, 특정 경우의 세부 구현에 대해서만 매우 구체적으로 관여해야 한다. 시스템이 현재의 목적에 들어맞을 뿐만 아니라 미래의 플랫폼으로서 적합하다는 것을 보장해야 하고, 나아가 사용자와 개발자가 똑같이 행복해지도록 해야 한다.

구역화

• 아키텍트는 서비스 간 통신 방법에 대해 고민하거나 시스템의 전반적인 상태를 적절히 모니터링하는 데 더 많이 할애하면서 구역 사이에서 발생하는 일을 더 걱정해야 한다.
• 서비스별로 팀들이 서로 다른 기술 스택과 데이터 저장소를 사용해도 문제없다 할 수 있지만, 여기서 다른 우려 상황이 발생할 수 있다.
• 각 팀이 서로 완전히 다른 저장소를 사용한다면 대규모로 운용할 때 문제가 될 수 있기에 넷플릭스는 데이터 저장 기술을 대부분 카산드라로 통일했다. 비록 모든 경우에 적합한 최선의 대응책은 아닐지라도, 넷플릭스는 카산드라와 관련된 도구 및 전문지식을 통해 얻는 가치야말로 몇몇 특정 태스크에 더 적합할 수 있는 다수의 이종 플랫폼 확장을 지원하고 운영하는 것보다 더 중요하다고 생각했다.
• 만약 한 서비스는 HTTP 상에서 REST를 노출하고, 다른 서비스는 프로토콜 버퍼를, 또 다른 서비스는 자바 RMI를 사용하기로 결정한다면, 호출하는 서비스가 의사소통을 위한 다양한 스타일을 이해하고 지원해야 하므로 통합 작업은 악몽이 될 수 있다.
• 다이어그램 박스들 간에 벌어지는 이벤트를 걱정하고, 내부에서의 일에 대해서는 자유로워야 한다.

원칙적인 접근법

마이크로서비스 아키텍처는 결정해야 할 수많은 트레이드오프를 제공한다. 여기서 도움이 되는 것이 구조화, 프레이밍이다. 의사 결정을 프레이밍할 수 있는 가장 좋은 방법은 성취해야 할 목표에 기반하여 일련의 원칙과 실천 사항을 정의하는 것이다.

트레이드오프: 동시에 달성할 수 없어 한 목표를 택하면 다른 것을 포기해야 하는 상층 관계에 있는 상황 또는 그 상황 사이의 균형을 의미
프레이밍: 문제의 표현 방식에 따라 동일한 사건이나 상황임에도 불구하고 개인의 판단이나 선택이 달라질 수 있는 현상

전략적 목표

• 회사가 어디를 향해 나아가고 있는지, 그리고 고객을 행복하게 만들기 위해 어떻게 해야 할지 언급해야 한다.(예: 신규시장 개척을 위해 동남아시아로 영역 확장, 고객이 셀프서비스를 최대한 많이 사용하게 하자, 새로운 제품의 시장 출시 시간을 줄이자)
• 조직이 지향하는 바와 일치해야 한다.

원칙

• 목표를 위해 해야 할 일을 정렬하는 규칙으로, 때로는 변경될 수 있다.
• 목표: 새로운 제품의 시장 출시 시간을 줄이자 -> 원칙: 제품이 준비될 때마다 다른 팀과는 독립적으로 출시하자 (제품 출시 팀이 소프트웨어의 생명주기 전반에 대한 통제권을 가짐)
• 목표: 여러 국가에서 공격적으로 제품을 성장시키자 -> 원칙: 각국의 데이터 자치권 존중을 위해 시스템 전체가 지역적으로 배포될 수 있도록 이식 가능해야 한다

실천 사항

• 원칙을 실행하는 방법으로, 업무 수행을 위한 자세하고 실질적인 지침으로 대개 기술 명세적이다.
• 어떤 개발자든 이해할 수 있도록 충분히 구체적이어야 한다.
• 예: 코딩 지침 / 모든 로그 데이터의 중앙 수집이 필요하다 / HTTP/REST가 표준 통합 스타일이다
• 기술적 특성으로 인해 실천 사항은 원칙보다 더 자주 변경된다.
• 원칙과 마찬가지로 때때로 조직의 제약을 반영한다. (예: CentOS만 지원하는 조직)

원칙과 실천 사항의 결합

• 누군가의 원칙이 다른 사람에게는 실천 사항이 될 수 있다.
  • 우리는 HTTP/REST 사용을 실천 사항보다는 원칙이라고 부를 수 있다.
• 닷넷 팀과 자바 팀의 원칙이 서로 같더라도 공통된 실천 사항과 더불어 고유의 실천 사항이 별개로 존재할 ㅛㅜㅅ 있다.

실제 사례

• 실천 사항은 꽤 정기적으로 변하지만 원칙은 매우 정적인 움직임을 보인다.
• 각 항목에는 세부 사항이 뒤따르지만, 요약된 양식으로 명확히 설명하는 것은 매우 유용하다.

필수 기준

실천 사항에 따라 작업하고, 결정할 트레이드오프에 대해 고민할 때 시스템이 얼마나 많은 변동성을 허용할 수 있는지 생각해야 한다. 자율적인 수명주기를 가지면서도 함께 협업하는 수많은 작은 부품으로 구성된 응집력 있는 시스템이 되어야 한다. 그러므로 우리는 거시적 시각을 잃지 않으면서도 개별 마이크로서비스 간의 자율성 최적화와 관련한 균형을 찾아야 한다. 이를 위한 확실한 방법 중 하나는 각 서비스가 가져야 할 명확한 속성을 정의하는 것이다.

모니터링

• 서비스 간 경계를 넘어 시스템 상태를 일관되게 살펴볼 수 있어야 한다. 서비스 세부 상태가 아닌 시스템 전체 상태를 볼 수 있어야 한다.
• 푸시 메커니즘:
  • 각 서비스가 모니터링 데이터를 중앙 저장소에 밀어 넣는다.
  • 서비스 지표: Graphite, 서비스 상태: Nagios 를 사용할 수 있다.
• 폴링 시스템:
  • 각 노드로 부터 데이터를 가져온다.

인터페이스

• 서비스 간 인터페이스 기술의 개수는 가능한 한 최소로 유지하는 편이 새로운 소비자를 통합하는 데 도움이 된다.
• HTTP/REST를 택한다면 동사형, 명사형 중에 어느 쪽으로 쓸 것인지, 어떻게 리소스의 pagination을 처리할 것인지, 엔트포인트의 버전은 어떻게 구분할 것인지 고려해야 한다.

아키텍처 안정성

• 서비스가 하위 호출의 잠재적 실패에 적절히 대비하지 못할수록 시스템은 더 취약해진다.
• 모든 하위 서비스에 대해 최소한의 커넥션 풀을 관라하게 하거나, 모든 서비스가 서킷 브레이커를 사용하도록 할 수 있다. (11장)
• 응답 코드가 규약대로 동작해야 한다. 시스템이 빠르게 동작하더라도 이러한 규칙에 대해 엄격하지 않다면 취약한 시스템으로 남게 된다.

코드를 통한 통제

개발자들에게 우리가 바라는 각 서비스의 표준을 구현하도록 부담을 주지 않기 위해 모범사례(본보기)와 서비스 템플릿을 제공하자.

본보기

• 단순히 예시로 활용할 목적으로 만든 서비스가 아닌 우리가 실제 사용하는 서비스여야 한다.

맞춤형 서비스 템플릿

• 각 서비스에 필요한 핵심 속성들을 구현할 준비가 된 코드를 가지고 있다면 어떨까?
• JVM 기반 오픈 소스 마이크로컨테이너: Dropwizard, Karyon
• 서킷 브레이커를 의무화하고 싶다면 Hystrix 같은 라이브러리를 통합하거나 모든 지표를 중앙의 그래파이트 서버로 전송해야 한다는 실천 사항을 정할 수 있다.
• 우리에게 맞는 개발 실천 사항에 대한 서비스 템플릿을 맞춤화하면 팀은 더 빨라지고 개발자들도 서비스가 잘못된 행위에 빠지지 않게 방어할 수 있다.
• 팀의 언어 선택을 제한할 수도 있는데, 넷플릭스는 적절한 라이브러리를 사용하는 JVM과 로컬 통신하는 sidecar service를 사용함으로써 위험을 완화한다.

예외 처리

• 원칙과 실천 사항은 시스템 구축 방법을 안내한다. 그런데 만약 우리 시스템이 이들에게서 벗어나게 된다면 어떻게 될까? 단지 규칙에 대한 예외로 단정 짓기도 하지만 나중에 참조할 수 있도록 기록해둘 만하다.
• 충분히 많은 예외가 발견된다면 결과적으로 현실을 재인식시킬 수 있도록 원칙과 실천 사항을 변경하는 것이 타당할 수 있다.
• 예) 데이터 저장소로 항상 MySQL을 사용 -> 대규모 볼륨 증가가 예상되지 않는 대부분의 저장소 요건에는 MySQL을, 그렇지 않을 경우에는 카산드라를 사용

중앙에서의 거버넌스와 지휘

• 아키텍트의 담당 업무 중 하나는 거버넌스다.
• 거버넌스: 아키텍트의 업무 중 하나가 기술 비전을 결정하는 것이라면, 거버넌스는 우리가 구축하는 결과물이 해당 비전과 일치함을 보장하고, 필요할 경우 비전을 진화시키는 것이다.
• 각 개발팀의 기술전문가로 구성된 다수의 그룹을 보유하게 하고 아키텍트는 이들 그룹이 거버넌스에 대한 책임을 수행하도록 해야 한다.
• 본인이 옳다는 사실을 인지하고, 팀의 의견을 기각할 때도 그 행동이 본인의 지위를 약화시킬 수 있을 뿐만 아니라 팀에게는 발언권이 없다고 느끼게 만들 수도 있음을 인지해야 한다.

팀 만들기

• 기술 리더의 역할은 사람들이 스스로 비전을 이해하도록 그들의 성장을 도복, 비전을 결정하고 구현하는 데 적극적으로 참여할 수 있도록 만드는 것이다.
• 거대한 모놀리식 시스템에서는 사람들이 성장하고 무엇인가를 소유할 기회가 거의 없는 반면, 마이크로서비스에서 우리는 독립적 수명주기를 가진 수많은 자율적인 코드베이스를 가진다.
• 훌륭한 소프트웨어는 훌륭한 사람에 의해 만들어진다.

마치며

• 비전
  • 명료하게 소통되고, 시스템이 고객과 조직의 요구 사항을 충족하도록 돕는 기술 비전이 있는지 확인하라.
• 공감
  • 고객과 동료에 대한 여러분 결정의 파급력을 이해하라.
• 협업
  • 비전을 정의하고, 다듬고, 실행하기 위해 가능한 한 많은 동료와 협업하라.
• 적응성
  • 기술 비전이 고객과 조직이 요구하는 것을 반영하는지 확인하라.
• 자율성
  • 여러분 팀의 표준화와 자율성 사이에서 올바른 균형을 찾아내라.
• 거버넌스
  • 시스템이 기술 비전에 맞게 구현되고 있는지 확인하라.

3장 서비스 모델링하기

마이크로서비스가 무엇인지 알았고 주요 혜택까지 이해했다. 이제 장점을 극대화하고 잠재적인 단점을 회피할 수 있는 마이크로서비스의 경계에 대해 생각해보자. 그러기 위해서는 작업할 대상이 먼저 필요하다.

무엇이 좋은 서비스를 만드는가?

느슨한 결합

• 서비스가 서로 느슨히 결합되어 있으면 하나의 서비스가 변경될 때 다른 서비스가 변경되는 일이 없다.
• 느슨하게 결합된 서비스는 그와 협업하는 서비스에 관해 알 필요가 없다. 이는 서비스 간 호출 타입의 제한을 의미할 수도 있다.
• 마이크로서비스의 요점은 시스템의 그 어떤 부분도 추가 변경할 필요 없이 특정 서비스를 변경하고 배포할 수 있다는 것이다.

강한 응집력

• 여러 곳에서 행위를 변경해야 한다면 해당 변경 사항을 적용하기 위해 많은 서비스를 릴리스해야 할 것이다. 이것은 느리고 위험하다.
• 서로 연관된 행위가 한 곳에 모이고, 다른 경계와는 가능한 한 느슨하게 소통할 수 있도록 우리 문제 영역 내에서 경계를 찾자.

경계가 있는 콘텍스트

도메인 주도 설계: 모든 도메인은 경계가 있는 콘텍스트들로 구성되며, 각 콘텍스트 내에는 외부와 통신할 필요가 없는 것뿐만 아니라 경계가 있는 다른 콘텍스트 외부와 공유되는 모델이 함께 존재한다. 모든 콘텍스트에는 명백한 인터페이스가 존재하고 이것은 어떤 모델이 다른 콘텍스트와 공유될지 결정한다.

감춰진 공유 모델

• 재무부서는 창고 내부의 세부 업무에 대해 세세하게 알 필요는 없지만 적어도 몇 가지는 알아야 한다.
• 재무부서 직원들은 회사 평가를 산출하기 위해 우리가 가진 재고 품목 정보가 필요하며, 따라서 재고 품목은 두 콘텍스트 간의 공유 모델이 된다.
• 창고 콘텍스트에 있는 재고 품목의 모든 것을 노출할 필요가 없고, 재고 품목에 내부적인 것을 기록하더라도 창고 내에서만 유지되며 공유 모델에 노출할 필요는 없다.

모듈과 서비스

• 어떤 모델을 공유해야 하는지, 그리고 어떤 내부 표현을 고유하면 안 되는지 명확히 고려함으로써 강한 결합을 회피한다. 또한 서로 조화를 이루는 비즈니스 역량(capability)들이 존재하는 도메인 내부의 경계를 식별하며 높은 응집력을 제공한다.
• 관련된 코드를 한데 모으고 시스템 내의 다른 모듈과의 결합도를 낮추기 위해 프로세스 경계 내에서는 모듈을 사용할 수 있다.
• 도메인에서 경계가 있는 콘텍스트들을 발견했다면 공유되고 감춰진 모델을 이용하여 그것들을 코드 내에서 모듈로 모델링하자.
• 처음 시작할 때는 새로운 시스템을 더 모놀리식한 쪽으로 유지하자. 서비스 경계를 잘못 정하면 큰 비용이 들게 되므로 새로운 도메인 영역에 익숙해져서 안정화될 때까지 기다리는 것이 현명하다.
• 서비스 경계가 도메인 경계가 있는 콘텍스트와 정렬되고, 마이크로서비스가 경계가 있는 콘텍스트를 잘 대표한다면, 우리의 마이크로서비스가 느슨히 결합되고 강하게 응집되도록 보장한다는 점에서 아주 좋은 출발을 하고 있는 것이다.

성급한 분해

• 서비스 경계에 대한 초기 견해가 옳지 않으면 서비스 간의 수많은 변경과 높은 비용 소모를 초래한다.

비즈니스 능력

• 경계가 있는 콘텍스트에 관해 고민할 때는 공유 데이터 관점이 아닌 나머지 도메인을 제공하는 콘텍스트의 능력 관점에서 봐야 한다.
• 두 콘텍스트 간에 공유 모델이 필요할 때 '이 콘텍스트는 무엇을 하는가?', '그 일을 하기 위해 어떤 데이터가 필요한가?'를 먼저 생각하자.
• 이들 능력이 서비스로 모델링될 때 그것은 네트워크를 통해 다른 협업자(서비스)에 노출될 주요 행위가 된다.

거북이 밑에 거북이

• 경계가 있는 콘텍스트들은 더 많은 경계가 있는 콘텍스트들을 내포할 수 있다.
• 마이크로서비스의 경계를 고려할 때는 우선 더 넓고 큰 단위의 콘텍스트 관점에서 생각한 뒤 접합부의 분리를 통한 혜택을 발견했을때 내포된 콘텍스트에 따라 세분화하자.
• 완전 분리 방식 대신 내포된 방식을 선택하는 것은 조직 구조를 기반해야 한다.
  • 창고 내에 주문 조달, 재고 관리, 제품 인수가 각기 다른 팀에 의해 관리된다면 그들은 최상위 계층의 마이크로서비스가 될 자격이 있다.
  • 반면 한 팀에 의해 관리된다면 내포 모델이 더 합리적일 것이다.
  • 이는 조직 구조와 소프트웨어 아키텍처 간의 상호작용 때문이다. (10장)
• 내포 방식은 창고 콘텍스트 내 각각의 서비스에 대해 스텁을 만들 필요 없이 더 큰 단위의 API를 테스트하면 된다. 이는 더 큰 범위의 테스트를 고려할 때 분리 단위로 활용될 수 있다.
  • 스텁(stub): 기존 코드를 흉내 내거나 아직 개발되지 않은 코드를 임시로 대치하는 역할을 한다. 스텁은 일반 소프트웨어 개발과 테스팅을 포함해서 특히 이식과 분산 컴퓨팅에 유용하다.

비즈니스 콘셉트 관점에서의 커뮤니케이션

• 비즈니스 콘셉트 관점에서 마이크로서비스 간의 커뮤니케이션을 생각하는 것도 중요하다.
• 비즈니스 도메인에 기반을 둔 소프트웨어 모델링은 경계가 있는 콘텍스트 개념에 멈춰서는 안 된다.
• 조직 내에서 공유되는 동일한 용어와 개념은 인터페이스에 반영되어야 한다.

기술적 경계

• 모놀리식 시스템을 수직적인 비즈니스에 초점을 맞춰 스택을 나누는 대신 이전에 동작 중인 API를 골라서 수평으로 나누게 될 경우는 기술 접합부를 찾는 첫 번째 목표가 아닌 두 번째 목표가 되어야 한다. (기술 접합부에 따라 서비스 경계를 모델링하는 결정이 항상 잘못된 것은 아니다)

마치며

• 느슨한 결합과 높은 응집력의 이중 혜택을 가져다주는 접합부를 어떻게 찾는지 배웠다.
• 경계가 있는 콘텍스트는 이들 접합부를 찾는 데 중요한 도구고, 마이크로서비스를 이 경계에 정렬하여 우리의 최종 시스템이 온전한 장점들을 유지하도록 만들어야 한다.
• 마이크로서비스를 어떻게 더 세분화할 수 있는지에 대한 힌트를 얻었다.