[0504] 마이크로서비스 - 도메인 주도 설계

• 도메인 지식
  • 어떤 산업 또는 분야를 이해하기 위한 지식
• 도메인
  • 지식, 영향력, 활동 영역
  • 개발 분야에서는 소프트웨어로 해결하려는 문제의 영역을 의미
• 객체 지향 프로그래밍에서는 도메인이 클래스(상태(property), 동작(method)을 가지는 객체)로 표현됨
• 도메인 주도 설계(Domain Driven Design)
  • 하나의 도메인 모델에 대한 이해관계가 각자 다름을 인정
  • 각 팀에 적합한 하위 도메인(주문, 배달, 결제 등)을 설정
  • 해당 하위 도메인에 대한 맥락을 알고 있는 사람이 따라야 할 비즈니스 규칙에 대한 경계를 설정
• 예시: 주문
  • 결제팀
    • 주문이란 “결제”다
    • 상태 : status, orderTotal, transction
    • 동작: pay(), cancel()
  • 배달팀
    • 주문이란 “배달”이다
    • 상태: status, scheduledPickupTime, scheduleDeliveryTime
    • 동작: assignCourier()
  • 가맹점팀
    • 주문이란 “주문서 발행”이다
    • 상태: status, requestedDeliceryTime, preparedByTime, quantity, item
    • 동작: aeecpt(), reject(), noteReadyToPickup()
• 보편 언어(ubiquitous language)
  • 도메인의 특정 업무와 관련된 사람들 사이에서 통용되는 개념
• 한정된 맥락(bounded context)
  • 한정된 맥락 없이 모놀리틱(단일 프로그램) 아키텍처로 구성한다면?
    • 클래스 이름부터 통일이 안됨
    • 클래스가 비대해질 우려가 있음 → 단일 책임 원칙(SRP) 위배
    • 클래스를 분리하더라도 의존 관계를 신셩써야 함
• DDD가 제안하는 해결책
  • 업무 범위를 나눠라
    • 모델의 경계를 분명하게 구분짓고, 업무 범위 내로만 아키텍처를 구성 → bounded context
    • 보편 타당한 클래스 이름 짓기가 가능해지며, 모든 도메인에 용어를 맞추기 위해 모호한 단어를 쓸 필요가 없음 → ubiquitous language
  • 서비스를 나눠라
    • 데이터베이스도 서비스 별로 둘 것
• 마이크로 서비스 아키텍처는 DDD를 실천하기에 딱 맞음
• 특징
  • 유지보수에 유리하고, 테스트가 가능해야 함
  • 느슨하게 결합되어야 함
  • 독립적으로 배포 가능함
  • 비즈니스 역량을 중심으로 구성해야 함
  • 작은 팀에 의해 소유됨
• 마이크로서비스 아키텍처는 DDD를 실천하기 위한 방법 중 하나이며, DDD의 유일한 해결책은 아님(마이크로서비스 ≠ DDD)
• 마이크로서비스 아키텍처에 DDD를 도입하기 위해
  • 도메인 지식을 가진 엔지니어가 팀마다 있어야 함
    • 자연스럽게 기능 조직이 아닌 목적 조직화 됨
  • 여러 서비스가 잘 결합할 수 있게 디자인해야 함
    • 하지만 동시에 다른 서비스에 지나치게 의존해서도 안됨
  • 서비스를 오케스트레이션 해야 함
    • 오케스트레이터는 각 서비스가 죽는지 안죽는지 여부, 트래픽이 수용 가능한지 아닌지 여부, 인프라 유지보수(업그레이드, 패치 등) 업무 등에만 집중
• 마이크로서비스로 소프트웨어를 작성할 때
  • 소프트웨어 작성에 앞서 팀의 일하는 방식을 보다 독립적으로 만들어내야 함
  • 반대로 마이크로서비스 아키텍처를 통해, 팀의 일하는 방식이 보다 독립적으로 만들어질 수 있음
  • 즉, 문화로서의 DevOps를 실천해야만 가능