언제 맥락을 나누고, 어떻게 연결할까?
도메인 스토리텔링 응용 10
<시스템 구동의 맥락(context) 파악하기>편에서 맥락에 대해 다뤘다. 스타벅스 사업 모델이 맥락도의 예시였다.
다른 사업을 하면 맥락이 달라지고 당연히 도면도 바뀐다. <시스템 구동의 맥락(context) 파악하기>편에서 다룬 세 가지 전형 혹은 원형 중에 하나가 스타벅스이다. 영어 표현 Archetype은 설명이 필요없는 전형이나 원형을 말한다. Lean Stack 서비스가 Lean Canvas 샘플로 제공하는 전형 세 가지가 있다. 그 중 하나가 지난 글에 다룬 스타벅스이고, 그 외에 두 개가 더 있다.
양면 시장에 대한 맥락 표현
아래 그림이 두 번째 원형인데, 페이스북의 린 캔버스이고 양면 시장을 대표한다. 맥락 표현에 초점을 맞추기 위해 다른 요소는 무시하고 빨간 색과 파란 색으로 색칠한 부분 위주로 보자.
고객 구분(Customer Segments)과 고유 가치 제안(Unique value proposition)을 취해서 UML 표기(정확하게는 유스케이스)로 그려보면 아래와 같다. Lean Canvas를 쓰임새도(Use Case Diagram)으로 변환한 것이다. 이렇게 되면 캔버스가 설명하는 비즈니스 모델의 맥락을 가장 높은 수준으로 추상화 한 것이다. 이것을 맥락도(context diagram)라고 부른다.
두 개의 전혀 다른 입장을 하나의 맥락에 담은 것이다. 이대로 프로그램을 구현하면 소위 말하는 한통의 구조 즉, 모노리식 (아키텍처를 취한) 시스템이 만들어진다. 소규모 팀이거나 응용 프로그램이 아주 복잡하지 않을 때는 효과적일 수 있다.
양면 시장에 맞게 맥락 구분하기
편리하게 프로그램을 무료로 쓰면서 소식을 남기고 친구와 공유하는 즐거움을 추구하는 사용자의 맥락과 이렇게 연결된 인맥과 사용자 콘텐츠를 이용해서 타게팅이 수월할 광고를 판매하는 일은 전혀 다른 맥락이다. 따라서, 시스템이 커지면 서로의 입장(이해관계)에 따라 구성원들 사이에 갈등과 혼선이 생길 수 있다. 의사소통을 원활하게 하기 위해서 이 둘을 구분할 수 있다.
이렇게 되면 동일한 시스템이지만 입장에 따라 맥락이 둘로 나눠질 수 있다.
나는 본질적으로 마이크로 서비스가 등장해야 하는 맥락을 이것이라고 본다. 소프트웨어 개발에 있어서 대부분의 기법과 방법론과 등장하는 이유는 복잡도를 제어하기 위한 것이다. MSA라는 아키텍처도 DDD라는 개발기법도 모두 복잡도를 제어하기 위해 등장한 사고법이다.
마법은 Loosely Coupled
이렇게 맥락을 구분하면 장단점을 무엇일까? 한번에 다룰 숫자가 줄어든다는 점은 장점이다. 현대인은 누구나 알고 있는 분업의 효율성과 같은 이치고, 8살 우리 아들이 초등학교 컴퓨터 시간에 몇 주 동안 배우는 폴더 만들기도 같은 이치를 사용하는 방법이다. 하지만, 나누어진 것들 사이에 연결을 어떻게 할 것인가? 내가 소프트웨어 공학을 전공할 때 매료된 개념이 있는데, 그게 바로 Loosely-coupled 이다. 위키피디아 정의를 보자.
In computing and systems design a loosely coupled system is one
1. in which components are weakly associated (have breakable relationship) with each other, and so, changes in one component least affect existence or performance of another component.
2. in which each of its components has, or makes use of, little or no knowledge of the definitions of other separate components. Subareas include the coupling of classes, interfaces, data, and services. Loose coupling is the opposite of tight coupling.
이 매력적인 개념을 소개하려니 기대도 되고 긴장도 된다. 그런데 또 글이 길어져 다음에 이어가기로 한다.
지난 도메인 스토리텔링 응용
6. 도메인 모델, Ongoing 설계 그리고 정원관리
7. 입장에 맞춰 맥락을 나눈 BoundedContext
