[공부메모] 마이크로서비스 이해 Vol4

Vol1: 마이크로서비스 개요->htps : // 코 m / 게 t ぁ st - 엔후 r 마치 온 / ms / 959d12 54 378
Vol2 : DDD (Domain-Driven Design)를 이용한 Microsoft 서비스 설계 접근법 -> htps : // 코 m / 게 t ぁ st ン フ r 마치 온 / ms / 5 2088 952c2562347f
Vol3 : 전술 DDD를 이용한 마이크로 서비스 설계 -> htps : // 코 m / 게 t ぁ st - 엔후 r 마치 온 / ms / 7d191527 7
Vol4: 마이크로서비스 경계의 식별*이번

이번 포커스

Microsoft의 Azure Docs에서 다양한 기능과 아키텍처 등이 정리되어 있기 때문에,
이번에는 마이크로 서비스 관련으로 아래 페이지를 요약합니다. なるべく短い言葉を使って。◆ 마이크로서비스 경계 식별
htps : // / cs. mic로소 ft. 코 m / 자 jp / 아즈레 / 아 r 치 테 c 얽힌 / 미 c 로세 r

도메인 모델에서 마이크로서비스로 이어지는 접근법

애플리케이션에서 마이크로서비스 식별

마이크로서비스의 기능이, 복수의 문맥에 걸치고 있지 않는 것을 확인. 넘어가면 도메인 분석을 수정해야합니다.

도메인 모델의 집계를 확인.

적절한 집계에는 다음과 같은 특징이 있다.

집계는 기술 관점이 아니라 비즈니스 요구 사항에서 파생됩니다

집계에는 고응집도가 필요.

집계는 느슨한 결합이다.

도메인 서비스는 여러 집계에 대한 상태 비저장 작업입니다. 다중 마이크로 서비스를 포함하는 워크 플로우입니다.

기능 이외의 요구 사항 검토. 기능 이외는 팀 규모, 데이터 유형, 기술, 확장성, 가용성, 보안 등.

위의 후에는 다음 기준으로 설계 검증

각 마이크로서비스는 하나의 역할만 가지고 있다.

서비스간에 빈번한 호출이 발생하지 않는다. 자주 일으키면 하나로 하는 것이 좋을지도 모른다.

각 마이크로서비스는 팀이 수용할 수 있는 규모여야 한다.

다른 서비스에 의존하지 않는 것. 「A를 배포하지 않으면 B가 배포할 수 없다」라고 하는 것이 없는, 즉 개별적으로 전개할 수 있는 것.

※ 하나의 MS를 복수로 분할하는 편이, 복수의 MS를 리팩토링하는 것보다 간단하다.

드론 배송 앱에 마이크로 서비스 적용

지금까지의 검토에 근거한 MS 설계 개요도↓

- 이하의 요인에 대해서도 고려가 필요.
- 네트워크 오버헤드가 있다.
- 데이터 스키마가 적합합니까? 새롭게 창조할 필요가 있는가?
- 레거시 체계는 인가?
- 다른 컨텍스트를 담당하는 팀과 쉽게 연락/연계 할 수 있습니까?

감상

다음 공부 후보.
- 소프트웨어 개발 관련 -> 객체 지향, 클린 아키텍처, 레이어드 아키텍처, 헥사고날 아키텍처
- 애자일 개발
- API