Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

SOA 는 서비스들의 재사용에 중점을 두지만 MSA 는 서비스들의 독립을 추구한다.

...

경계식별

...

SOA

...

Image Removed

...

Image Removed

Image Added


특성

특성및 주의점

  • SOA는 각 레이어의 통신방법을 중시하며, 재사용을 위해 공유할수 있으며 모놀리식에 가까울수 있다있습니다. 
  • MSA는 배포와 업무 조직단위의 서비스(레파지토리) 자체가 분리된다. 서비스내에 동일 로직이 생길수 있으며 각 서비스가 책임진다.
  • MSA에서 서비스 오케스트레이션 영역에 목숨걸지말고,  유지보수와 배포에 포커싱해야합낟포커싱해야합니다. ( 데브옵스는 반드시 해야한다.데브옵스 )
  • MSA에서 API 게이트 웨이를 반드시 사용해야하는 강박관점도 없애야 한다.

...

애플리케이션 아키텍처는 그것을 개발하는 조직의 구조를 그대로 반영한다는 뜻입니다. 따라서 이 법칙을 역으로 이용해서 조직의 구조가 마이크로서비스 아키텍처에 고스란히 반영되도록 설계해야 합니다. 이렇게 하면 개발 팀과 서비스를 느슨하게 결합시킬 수 있습니다.



서비스 경계식별

마이크로 서비스가 무조건 작은 단위로 쪼게어, 우리가 운영을 하기 힘든케이스가 되어선 안됩니다.

중요한것은 "너무 크지도 작지도 않은것" 이며 사실은 우리에게 적절한 신중하게 디자인한 도메인모델을 사용하는것입니다.

무조건 작게 만드는것이 아닌, 어떻게 구분을 할것인가? 이며 DDD의 Bounded Conxtext 는 이러한 점에서 도움을 줄수 있습니다.

DDD가 마치 MSA를 위한것인것처럼 보일수 있는데, SOA/모놀리식 등에서도 활용될수 있습니다. 

경계가 꼭 배포단위가 될필요가 없으며, 리팩토링을 통해서도 경계를 만들수 있기때문이며 필요하면 독립될수 있기때문입니다.


Image AddedDDD의 바운디드 컨텍스트

 

소프트웨어의 관심사를 도메인을 바탕으로 분명하게 분리시켜야 한다.

상호 의존성을 갖기 때문에, 서브도메인으로 나누지 않는다면 변화가 계속됨에 따라 훨씬 큰 부담을 지게 된다.

DDD의경우 도메인을 베이스로 분리하는 방법에 대해 설명을 합니다. 


참고링크