GraphQL과 도메인 이벤트의 관계
디지털 코어의 시작 4
영모님이 <GraphQL 그리고 MSA>란 글을 썼다. 내가 기술 검토 요청을 한 항목인데, 기술 검토 후에 글로 정리해 주었다. 왜 기술 검토를 요청한 것일까? 단순 호기심은 아니어야 하지만, 스스로도 명확하지 않기 때문에 글을 써서 언어화를 시도해 본다.
도메인 이벤트 기반 프로그래밍과 GraphQL의 만남
시작이 다소 막막했는데, 마침 어제 <도메인 이벤트 정의하기>편을 펼쳐본 탓에 인용해 둔 빌딩 블록과 GraphQL 글 사이의 연관성 찾기로 시작해 본다.
오호... 실마리가 잡힌다. View와 BFF(Backend for Frontend)를 연결할 수 있다. <왜 디지털 코어인가?>편에서 인용한 포트앤어댑터 아키텍처를 표현한 그림을 등판시키면 Use Case를 BFF층에 묶는 방법이라고 말할 수도 있다. 아래 그림을 기준으로 조금 더 상세하게 풀어보면
Web Adapter가 View를 호출할 때 개별 View는 React가 제공하는 방식에 따른다고 가정하고 설명에서 제외한다. 그렇게 되면 React 기반의 아키텍처가 된다. 거기서 특수한 점은 마치 Domain object를 묶은 빌딩블록으로 Aggregate가 존재하는 것처럼 View에게 요구되는 Entity에 대한 쓰임새(Use Case)의 묶음으로 BFF를 구성한다.
UnderFetching/OverFetching을 막기 위한 빌딩블록
그러면 질의 형태가 완전히 다른 유형의 프로세싱을 묶을 수 있다. 그 모양이 어떤 식이 될지는 아직 사고 실험 단계라 알 수 없다. 다만, 영모님 글에서 UnderFetching이나 OverFetching이라는 표현으로 나타내는 비효율을 줄일 수 있는 적절한 덩어리를 찾을 수 있을 듯하다.
이러한 논리에 따르면 GraphQL의 Use Case의 유형이 BFF 단위로 크게 대별된다. 이렇게 묶으면 어떤 효과를 발휘할 수 있을까? 일단 다양한 데이터 스토리지 기술에 대해 유연성을 가질 수 있다. DBMS가 아니라 Redis를 써야 할 구간과 그렇지 않은 구간에 대한 판단 그리고 이를 담은 코드에 경계를 두어 보관할 수 있다. 흔히 말하는 모듈화를 강화하는 일이고, 클라우드 네이티브를 향해가는 기술 흐름에 잘 어울린다.
두 가지 형태의 Aggregation
영모님 글에서 Composition이라는 단어를 보자 경험적으로 예민하게 된다. 영어 단어가 같다고 모호하게 쓰면 혼선이 발생하는 경우가 있어서 그런 듯하다. 앞서 인용한 빌딩 블록 이름 중에 Aggregate가 있다. 이는 domain object의 군집을 대표하는 빌딩 블록이다. View의 모음에도 Aggregate란 표현을 쓸 수 있다. 예를 들어, Aggregate views 같은 표현은 업계에서 널리 쓰이기도 한다.
하지만, 단순히 화면을 모아두는 일과 대량 데이터에서 필요한 데이터만 취합해서 한 번에 보여주는 일과 DDD에서 기원한 Aggregate는 구분하는 편이 좋다. 그 이유는 아래 그림을 차용해서 설명해 보겠다. 앞서 인용한 이벤트 주도 개발을 위한 7개의 빌딩 블록 중에서 3개는 아래 그림에 따르면 모두 Entity의 구성과 처리 방법에 대한 빌딩 블록이다.
Entity를 처리함에 있어 단일 DBMS에 SQL로 처리하는 방법이 가능하다. 옛날 표현으로 하면 Client-Server의 초창기 방식이고 마틴 파울러가 말한 Transaction Script로 프로그래밍을 짜는 방식으로 MyBatic, iBatis, DAO 같은 기술이나 어휘가 프로그램에 들어가면 대체로 이런 식이라고 할 수 있다. 이런 상황을 위 그림에 맞춰 설명하면, Use Case가 SQL 호출하는 함수나 함수 내부의 어떤 문장 수준으로 만들어진다. 관리가 불가능할 수준의 방대한 양이 만들어진다. 비즈니시 로직을 응집력 있게 수정하는 일이 불가능할 가능성이 높다.
그와 달리 ORM 기술을 쓰고 SQL과 비즈니스 로직을 구분하려는 시도가 있다. DDD가 이를 위한 빌딩 블록을 제시했고, 비교적 소수의 개발자들이 쓰고 있다. 이 방법을 쓰다 보면 동일한 Entity에 대해 대량 처리할 때와 여러 테이블의 관계로 구성된 Entity의 세밀한 수정을 하나로 묶는 일에 곤란을 겪기 마련이다. 이때 그 문제를 다루는 패턴이자 빌딩 블록이 Aggregate이다. 내가 편한 말로 하면 객체 그래프를 사용하여 객체라는 단위로 변경 관리를 하려는 접근이다. 변경 내용을 도메인을 객체로 표현한 문법에 담겠다는 시도다. 이는 기본적으로 View와는 무관하게 구성해야 효용성을 갖는다.
GraphQL과 도메인 이벤트의 관계
영모님 글로 인해 즉흥적으로 쓰다 보니 두서없이 마무리할 위기에 빠진다. 흐름을 멈추고 전체 글의 주제를 말해보자. 우리의 여정은 현재 도메인 이벤트의 채용이다. 그것과 기술 검토 대상인 GraphQL은 무슨 관련이 있나?
오호... Aggregation 복잡도의 분산이다. 안전한 변경을 가능하게 하는 응집력(cohesion)을 위한 노력이다. 일종의 Design Play이기도 하다. GraphQL은 복잡한 화면의 요구와 네트워크 사용을 하나의 방법으로 가능하게 해 준다. 영모님 표현을 빌면 API Composition의 책임을 GraphQL이 맡을 수 있다.
반면에 한 번에 수정해야 할 Entity Graph(데이터베이스 연결 등으로 보관하는 객체의 규칙)에 대한 것은 GraphQL과 무관하다. QL이 Query Language란 사실이 바로 그 이유다. 다시 말해, 객체의 생성이나 수정, 제거의 문제를 비교적 응집력 있게 구성할 수 있는 방법으로 다른 수단이 필요한데, 도메인 이벤트가 바로 시도해 볼 만한 가치가 있는 후보라고 믿는다.
지난 디지털 코어의 시작 연재
2. 도메인 이벤트 정의하기
3. 왜 디지털 코어인가?
