brunch

You can make anything
by writing

C.S.Lewis

by 안영회 습작 May 11. 2022

아키텍처 그림 가운데 있는 데이터

MSA 기술과 적용 연구 8

지인의 페이스북에서 흥미로운 대화를 만났다. 같은 현상에 대한 다른 해석이 이 글을 쓰게 만들었다.


서비스 계층 아키텍처 패턴

가운데 데이터 소스가 있다는 그 그림은 마틴 파울러의 작품이었다. 책으로 출간되었던 마틴 파울러의 기업 응용 프로그램의 패턴 중에 하나인 서비스 계층을 도식화 한 그림이다.

서비스 계층은 지인이 정확히 이틀 전에 올린 헥사고날 혹은 포트앤 어댑터라고 불리는 패턴과 상충된다. 같은 역할에 대해 다른 구성요소로 설명하는 패턴이니까 둘 중 하나를 택해야 할 듯하다. :)

이에 대한 이야기는 <실용적인 포트와 어댑터 적용>편에 있으니 여기서는 다루지 않는다. 여기서 다룰 문제는 중앙에 있는 데이터소스에 대한 이야기다.


중앙에 있는 데이터소스를 어떻게 볼 것인가?

가운데 그린 이유는 뭘까? 나는 가운데 Entity로 끝나는 그림보다는 오래되었지만 Data Source Layer를 가운데 둔 그림이 마음에 든다. 왜냐하면 명확하게 레코드 저장소에 해당하는 표현이 있어서다. 선호를 떠나 왜 가운데 Entity 혹은 Data Source Layer가 있는가? 

출처: 네이버 한자사전


아마도 (한자 사전의 中心 뜻과 같이) 중요하고 기본이 되는 부분이기에 그럴 듯하다. 데이터는 보통 프로그램이 배포된 이후 사용자가 만든다. 그리고 상업용 프로그램의 경우 사용자가 만든 데이터를 프로그래머가 임의로 수정할 수는 없다. 그래서 보호해야 하는 자원이기도 하다. 또한, 해당 데이터를 기본으로 하여 다양한 쓰임새가 만들어지고, 사용자 기반이 생겨난다는 점까지 고려하면 당연하게도 응용 프로그램의 핵심이 데이터란 사실을 알 수 있다. 


데이터 저장을 여러 곳에 하는 MSA

MSA의 가장 큰 특징 중 하나가 데이터 저장을 여러 개의 데이터베이스에 나누어 보관하는 일이다. 이 분야의 대가라 할 수 있는 크리스 리차드슨이 정의한 Microservice Architecture 패턴에 등장하는 그림을 보자.

더불어 그는 '서비스당 데이터베이스(Database per service)'라는 패턴도 제시하고 있다. 해당 패턴을 따라가려고 하면 이렇게 질문할 수도 있다.

그렇다면, 서비스는 어떻게 나누는가?


앞서 말한 도메인 드리븐, 즉 여러분의 현장에 어울리는 답을 달아야 하는데 힌트를 드리면 얼마 전에 <동료의 도메인 스토리텔링 활용>편에서도 다룬 bounded context 를 활용하는 방법이 있다. Bounded Context에 대한 설명은 링크한 이전 글 참조에 맡긴다.


MSA 기술과 적용 연구 시리즈

1. MSA 기술이전 사업을 시작하다

2. 헤드리스 커머스와 SW 아키텍처 

3. 실용적인 포트와 어댑터 적용

4. 실전 마이크로서비스 아키텍처 적용

5. 느슨한 설계시점 결합이란 무슨 말인가?

6. 느슨한 설계시점 결합을 안하면 무엇이 문제인가?

7. 느슨한 설계시점 결합은 어떻게 구현하나?

브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari