독립적 배포

이 책의 저자의 의견은

• 한 가지를 골라야 한다면 '독립적 배포'를 선택

이를 위해

• 마이크로서비스 간 결합도를 낮춰야 함
• 즉 서비스 간에 명시적, 잘 정의되고, 안정된 명세/계약 필요

비지니스 도메인을 중심으로 모델링

도메인 기준으로 서비스 경계를 정의

• 즉, 한 마이크로서비스가 기능에 필요한 전체를 구현
• 새 기능 출시가 쉬워짐
• 다른 방식으로 마이크로서비스를 재조합하기 쉬워짐

한 기능의 구현이 여러 마이크로서비스에 걸쳐 있으면 기능 출시 비용이 올라감

• 서비스 간 조율, 순서 관리 등 더 많은 일을 해야함
• 여러 서비스에 걸친 변경은 가능한 덜 할 수 있는 방법을 찾아야 함

자신의 상태를 가짐

• 마이크로서비스는 DB를 공유하지 말아야 함
• 다른 마이크로서비스가 갖고 있는 데이터에 접근해야 하면 DB에 직접 접근하지 말고 API 등을 통해서 접근해야 함
• 데이터를 공유하지 않기 -> 구현을 감춤 -> 결합도를 낮춤

크기

"a microservice should be as big as my head" - James Lewis

• 내 머리가 이해할 수 있을 정도의 크기를 가져야 함
• 상황에 따라 다름: 오랜 경험자 vs 신규 입사자, 스타트업 vs 대기업

크기 보다는 다음 2 가지에 집중할 것

• 얼마나 많은 마이크로서비스를 다룰 수 있나?

• 마이크로서비스 증가 -> 복잡도 증가, 새 기술 습득 필요

• 마이크로서비스 경계 정의
  실타래가 복잡하게 얽히지 않도록

유연함

"microservices buy you options" - James Lewis

비용을 들여 미래에 유연해질 수 있는 옵션을 구매함

• 기술, 확장, 견고함 등에서 유연함 구매
• 아직 벌어지지 않은 미래를 너무 많은 옵션을 구매하는 것은 힘들게 하는 원인이 될 수 있음

그래서 점진적으로 마이크로서비스로 넘어가는 것을 권장

아키텍처와 조직을 맞춤

조직 구조 -> 아키텍터에 영향을 줌

• 아키텍처는 조직 구조를 닮기 때문

소프트웨어를 더 빨리 배포하길 원함

• 조직 간 이관이나 사일로를 줄여야 함
• 여러 직능을 한 조직에 모아 줄임

비지니스 도메인 -> 시스템 아키텍처를 주도하는 주요 원동력

[reference] https://www.youtube.com/watch?v=3pybGLmTREw