도메인 주도 설계 첫걸음 - 14장 마이크로서비스

범위

[Part 4] 다른 방법론 및 패턴과의 관계 - 14장: 마이크로서비스

개념 정리

• 서비스: 미리 정의된 인터페이스를 사용해 하나 이상의 역량에 접근하기 위한 메커니즘.
• 미리 정의된 인터페이스: 서비스로부터 데이터를 넣고 빼는 모든 메커니즘.
• 마이크로서비스: 자신의 마이크로 퍼블릭 인터페이스, 즉, 마이크로 프런트 도어(micro-front door)에 의해 정의되는 서비스.
• 함수(function): 모듈이 해야 하는 일. 즉, 비즈니스 기능.
• 로직(logic): 모율의 비즈니스 로직. 즉, 모듈이 자신의 비즈니스 기능을 구현하는 방법.
• 애그리게이트(Aggregate): 내부 비즈니스 규칙과 불변성, 로직의 복잡성을 감싸는 개별적인 비즈니스 기능 단위.

책에서 기억하고 싶은 내용

서비스란 무엇인가?

• 서비스의 퍼블릭 인터페이스는 서비스 자체, 즉, 서비스가 노출하는 기능을 정의한다.
• 잘 표현된 인터페이스는 서비스가 구현한 기능을 설명하기에 충분하다.

마이크로서비스란 무엇인가?

서비스형 메서드: 완벽한 마이크로서비스?

설계 목표

• 마이크로서비스 아키텐처의 목표는 유연한 시스템을 만드는 것이다.

시스템의 복잡성

• 적절한 마이크로서비스 기반 시스템을 설계하려면 글로벌 복잡성과 로컬 복잡성 모두를 최적화 해야 한다.
  • 로컬 복잡성: 각각의 개별 마이크로서비스의 복잡성
  • 글로벌 복잡성: 전체 시스템의 복잡성

깊은 서비스로서의 마이크로서비스

• 이 같은 모듈은 ‘유동적인 부분’을 만들어내고, 결국, 복잡성을 내포하는 대신 전체 시스템에 우발적 복잡성을 발생시킨다.

깊은 모듈로서의 마이크로서비스

• 깊은 모듈의 개념은 마이크로서비스 패턴과 다르다.
  • 마이크로서비스는 엄밀히 물리적은 경예를 나타내지만 모듈은 논리적 경계와 물리적 경계를 모두 나타낼 수 있기 때문이다.
• 단일 비즈니스 메서드를 구현하는 서비스는 얕은 모듈이다.
• 시스템의 복잡성
  • 깊은 모듈은 시스템의 글로벌 복잡성을 줄여준다.
  • 얕은 모듈은 로컬 복잡성을 감싸지 않는 구성요소를 도입해야 해서 글로벌 복잡성이 증가한다.
• 얕은 서비스는 수많은 마이크로서비스 지향 프로젝트가 실패하는 원인이다.

도메인 주도 설계와 마이크로서비스의 경계

바운디드 컨텍스트

• 마이크로서비스와 바운디드 컨텍스트 모두 물리적 경계다.
• 바운디드 컨텍스트와 마찬가지로 마이크로서비스도 단일 팀이 소유한다.
• 바운디드 컨텍스트와 동일하게, 충돌하는 모델은 인터페이스가 복잡해지므로 마이크로서비스로 구현할 수 없다.
• 마이크로서비스가 사실상 바운디드 컨텍스트다.
• 마이크로서비스와 바운디드 컨텍스트의 관계는 비대칭이다.
• 마이크로서비스는 바운디드 컨텍스트로 볼 수 있지만, 모든 바운디드 컨텍스트가 마이크로서비스인 것은 아니다.

애그리게이트

• 바운디드 컨텍스트는 가장 넓은 유효한 경계를 설정.
• 애그리게이트의 경계는 가능한 한 좁게 설정.
• 애그리게이트를 여러 물리적 서비스 또는 바운디드 컨텍스트로 분해하는 것은 최적이 아닌 원치 않는 결과를 초래한다.
• 애그리게이트와 자신의 하위 도메인에 있는 다른 비즈니스 엔티티와의 관계가 강할수록 얕은 개별 서비스가 된다.
• 애그리게이트를 서비스화해 모듈형 설계를 만들어내는 경우도 있다.
  • 대부분 이 같은 작은 크기의 서비스는 전체 시스템의 글로벌 복잡성을 증가시킨다.

하위 도메인

• 마이크로서비스를 설계하는 데 좀 더 균형 잡힌 휴리스틱은 비즈니스 하위 도메인의 경계와 서비스를 일치시키는 것이다.
  • 비지니스 도메인 관점에서 보면 하위 도메인은 역량이 어떻게 구현되는지 설명하지 않고 비즈니스 역량(무엇을 하는 비즈니스인지)을 설명한다.
  • 기술적 관점에서 보면 하위 도메인은 응집된 유스케이스의 집합을 대표한다.
    • 같은 비즈니스 도메인 모델을 사용하고, 같거나 밀접하게 관련된 데이터를 다루며, 강한 기능 연관성을 갖는다.
    • 유스케이스 중 하나에서 비즈니스 요구사항을 변경하면 다른 유스케이스도 영향을 받을 가능성이 높다.
• 하위 도메인을 마이크로서비스 설계를 위한 안전한 경계를 만드는 방법.
  • 하위 도메인의 크기와 ‘어떻게’보다는 ‘무엇을’에 중점을 둔 기능이 하위 도메인을 자연스럽게 깊은 모듈로 만든다.
  • 하위 도메인을 설명하는 ‘기능’은 더 복잡한 구현 상세인 ‘로직’을 캡슐화한다.
  • 하위 도메인에 포함된 유스케이스의 응집력이 결과 모델의 깊이를 보장한다.
  • 유스케이스를 작은 케이스로 쪼개면 더 복잡한 퍼블릭 인터페이스를 만들고 모듈은 더욱 얕아진다.
• 하위 도메인을 마이크로서비스로 만드는 것은 대부분의 마이크로 서비스를 위한 최적을 솔루션을 만드는 안전한 휴리스틱이다.
  • 솔루션은 비즈니스 도메인에 의존할 뿐 아니라 조직의 구조와 비즈니스 전략, 비기능 요구사항에도 의존한다.
  • 환경의 변화에 따르 소프트웨어 아키텍처와 설계를 끊임없이 적응시키는 것이 중요하다.

마이크로서비스의 퍼블릭 인터페이스 압축하기

• 도메인 주도 설계는 서비스의 경계를 찾는 데 쓰일 뿐만 아니라, 서비스를 깊게 만드는 데도 도움을 준다.

오픈 호스트 서비스(OHS)

• 오픈 호스트 서비스는 비즈니스 도메인의 바운디드 컨텍스트 모델을 시스템의 다른 구성요소와 연동하는 데 사용되는 모델과 분리해준다.
• 연동 지향 모델인 공표된 언어를 도입하면 시스템의 글로벌 복잡성이 줄어든다.
  • 서비스 사용자에게 영향을 미지지 않고 서비스의 구형을 발전시킬 수 있다.
  • 공표된 언어는 좀 더 제한된 모델을 노출한다.

충돌 방지 계층(ACL)

• 서비스를 다른 바운디드 컨텍스트와 연동할 때 복잡성을 줄여준다.
• ACL 서비스는 바운디드 컨텍스트를 사용하는 로컬 복잡성과 시스템의 글로벌 복잡성을 모두 줄여준다.
• ACL 서비스 덕분에 바운디드 컨텍스트를 사용할 때의 비즈니스 복잡성과 연동할 때의 복잡성이 분리된다.

결론

• 모든 마이크로 서비스는 바운디드 컨텍스트다.
• 모든 바운디드 컨텍스트가 반드시 마이크로서비스인 것은 아니다.
• 기본적으로 마이크로서비스는 서비스의 가장 작은 유효한 경계를 정의하는 반면, 바운디드 컨텍스트는 모델 전반의 일관성을 보호하고 가장 넓은 유효한 경계를 나타낸다.