Domain Driven Design

Jaeminst·2022년 4월 16일
0
post-thumbnail
post-custom-banner

도메인 주도 설계

도메인 지식

  • 어떤 산업 또는 분야를 이해하기 위해 필요한 지식

도메인

  • 지식, 영향력, 활동 영역
  • 개발 분야에서는 소프트웨어로 해결하려는 문제의 영역을 의미

도메인 주도 설계

  • 하나의 도메인 모델에 대한 이해관계가 각자 다름을 인정하고
  • 각 팀에 적합한 하위 도메인(주문, 배달, 결제 등)을 설정하고
  • 해당 하위 도메인에 대한 맥락을 알고 있는 사람이 따라야 할 비즈니스 규칙에 대한 경계를 설정하는 설계 방식

도메인 주도 설계의 주요 용어

  • 보편 언어 (ubiquitous language)
    • 도메인의 특정 업무와 관련된 사람들 사이에서 통용되는 개념
  • 한정된 맥락 (bounded context)
    • 모델의 경계를 분명하게 구분짓고, 업무 범위 내로만 아키텍처를 구성한다.
    • 서비스를 나눈다.
    • 데이터베이스를 서비스 별로 구분한다.

DDD와 마이크로서비스

  • 마이크로서비스 아키텍처는 DDD를 실천하기 위한 방법 중 하나이며, DDD의 유일한 해결책이 아님에 주의해야 한다.

도입하려면?

  • 도메인 지식을 가진 엔지니어가 팀마다 있어야 한다.
    • 자연스럽게 기능 조직이 아니라 목적 조직화 된다.
  • 여러 서비스가 잘 결합할 수 있게 디자인해야 한다.
    • 동시에 다른 서비스에 지나치게 의존해서도 안된다.
  • 서비스를 오케스트레이션 해야 한다.
    • 오케스트레이터는 각 서비스가 죽는지 안죽는지 여부, 트래픽이 수용 가능한지 아닌지 여부, 인프라 유지보수(업그레이드, 패치 등) 업무 등에만 집중한다.

콘웨이의 법칙(Mevlyn Conway, 1967)

  • 모든 시스템은 그 조직의 의사소통 구조와 동일하게 만들어진다.

마이크로서비스로 소프트웨어를 작성할 때에는 소프트웨어 작성에 앞서 팀의 일하는 방식을 보다 독립적으로 만들어내야 하며, 마이크로서비스 아키텍처를 통해 팀의 일하는 방식이 보다 독립적으로 만들어질 수 있다.

즉, 문화로서의 DevOps를 실천해야만 가능하다.

profile
DevOps !
post-custom-banner

0개의 댓글