마이크로서비스 개발을 위한 Domain Driven Design

Why DDD for Microservice Architecture?

실제 비즈니스 도메인을 우리가 만드는 아키텍쳐에 투영함으로서, 커뮤니케이션 코스트가 많이 줄어든다.

Starting with Events

앉을 자리가 없다. 짧은 시간동안 집중력있게 진행된다. 개발자 뿐만 아니라 모든 사람이 모여서 한다.

비즈니스 쪽 사람과 개발자가 얼라인하기 쉬운 방법이다.

Domain Events

주황색 스티커는 이벤트를 도출할 때 주로 사용한다. 비즈니스에서 발생하는 이벤트들을 나열하는 것을 이벤트 스토밍이라고 한다. 이런 이벤트는 과거형, 수동형으로 사용을 한다.

Command

이벤트의 소스가 되는 것이 command다. 파란색으로 액티비티를 진행한다.

Aggregate

마이크로서비스로 전환할 때 가장 중요한 것 중 하나이다. 커맨드가 aggregate에 영향을 주고, 그것이 이벤트로 넘어간다. Aggregate와 aggregate는 서로 Object로 레퍼렌싱 하지 않고 id로 레퍼렌싱한다. 즉 tightly coupling 되어있지 않다.

Putting it all together

이벤트는 시계열로 붙여 나간다.

커맨드와 이벤트는 짝으로 이뤄지지만, 커맨드가 너무 명시적인 경우 생략해서 다뤄볼거다.

주황색은 이벤트고 빨간색은 외부 시스템이다.

궁극적인 모양이다.

Boris

노란색이 Aggregate라고 할 때, 테크니컬한 implementation으로 가져갈 때 이것을 Boris diagramd이라 한다.

SnapE

일부 서비스에 대해 상세 스펙 즉 어떠 api를 가져갈지, 어떤 데이터를 가져갈지 도출을 한다.

예제

없는 것을 새로 만들거나, 있는 것을 마이크로 서비스로 옮길 때 둘 다 적용 가능하다.

이벤트 스토밍

내가 투자하고 싶은 주식을 검색하고, 매수 매도 기능을 가진 애플리케이션을 만들려고 해보자.

외부 시스템은 우리가 빌딩하고 있는 시스템의 바깥에 있는 것은 전부 외부 시스템이다. 꼭 회사 외부여야하는게 아니다.

그룹핑을 해야한다. 데이터의 오너쉽을 정해야한다.

그룹핑

알림은 사용자와 동떨어져있다. 그래서 별도의 공간으로 분리한다. 알림은 매수나 매도 등에서도 사용이 된다.

주식정보도 여기서 다소 동떨어져있으니 별도로 분리한다.

이렇게 연관된 것끼리 남으면 Aggregate를 지정해줄 수 있다. 노란색으로 표시를 했다.

일반적으로 Aggregate를 중심으로 도메인을 나누지만, 포트폴리오랑 거래이력 같은 경우 서로 의존성이 매우 높다. 이럴 때는 두 개 이상의 도메인으로 나눌 필요가 없다.

파란색으로 된 것이 바운디드 컨텍스트이고 노란색이 aggregate이다. 하나의 바운디드 컨텍스트에는 하나 이상의 aggregate가 있을 수 있다.

이것이 픽스가 되는 것이 아니라 계속적으로 발전할 수 있다.

컨텍스트 매핑

빨간색 선은 비동기이다.

SNAP-E