DDD의 BoundedContext가 우리의 이야기와 밀접해지다

첫 연재에서 소개한 개념 정제 후에 동료 개발자가 해당 내용 구현에 나섰습니다.
presentation
두 계층으로 나누어 연결한 상품 개념
이전에 그린 그림을 조금 수정해서 상황에 대한 설명을 보강합니다. Product와 Item 개념 사이에 그린 두 가지 관계를 동료 개발자가 구현한 것이 아닙니다. 그래서, 둘 사이를 연결하는 Catalog 개념을 추가하여, 그의 구현을 Catalog 개념 구현으로 바라보겠습니다.
presentation
두 개념 사이에 카타로그 개념을 추가하기

동료가 나의 개선 요구에 관심을 보였습니다

일상 작업 도구인 두레이 메신저가 반가운 소식을 전해왔습니다. 필자가 동료에게 상품 상태 머신[1]이라고 앞서 관련 로직을 지칭했기에 아래 예시와 같은 표현으로 작업을 작성했고, 통지가 날아온 것이죠.
presentation
필자가 일상업무에 사용하는 두레이 메신저 통지 기능
이러한 예시는 우리 조직에 배양된 SNS 쓰듯 일하는 방식입니다. 필자 역시 자연스럽게 두레이 댓글로 의견을 제시합니다. 구현 기능 설명에 상황 정보를 약간 덧붙여보는 것이죠. 开业는 개업을 뜻하는 중국어 표현입니다.
presentation
두레이 댓글을 이용하는 협업 사례

만나서 대화를 하고 나니

그랬더니 그가 찾아왔습니다. 아마도 제가 댓글을 올리기 전에 자신의 설계 아이디어에 대한 의견을 듣고자 온 듯 합니다. 필자가 메신저 알람을 보고 바로 회신하는 사이에 자리를 떠서 필자 옆으론 온 듯 합니다. 기왕 썼으니 필자가 쓴 내용을 보여 줍니다. 그러자 바로 본인이 주안점으로 설정한 전제사항을 말하고 의견을 묻습니다. 지난 글에 예로 써먹었던 바로 그 내용입니다.
item 구현에 있어서 물리적으로 공급받은 상품 1개와 대응하는 경우 먼저 구현하겠다
필자가 동의하고, 동료가 자리에 돌아간 후에 다른 일로 회의를 하고 왔더니 둘의 소통 내용을 반영해 바뀐 그림이 두레이에 올라와 있었습니다.
presentation
UML 문법으로 표기한 구성요소 관계도
시점에 필자의 지난 글을 노출하기 전인데, 공교롭게 필자가 고려하는 BoundedContext 구분을 다른 색으로 표현했습니다. 와우~

대화하듯 함께 개발하기

그리고 바로 다음 날, 필자의 글을 노출하고 아침에 링크를 알려줬더니 바로 읽고 진도를 나간다고 합니다.
presentation
동료와 위챗Wechat 대화
그 진도는 점심 먹고 두어 시간 지난 후에 바로 확인할 수 있었습니다.
presentation
두레이 메신저와 연결해 통지를 받는 Gitlab 이슈 등록
반가운 마음에 링크를 타고 Gitlab에서 질문합니다.
presentation
Gitlab 토론 기능을 이용한 개발 과정의 대화
대강 요약하면 Item을 별도 패키지[2]로 추가한 내용에 대한 질의 응답입니다.BoundedContext 개념을 고려했지만, 아직은 코드 저장소repository 안에서 패키지로만 구분했다는 이야기죠. 필요할 때 API를 나눠 마이크로 서비스 형태를 띄게 할 생각이란 부연을 읽을 수 있습니다. 필자의 개발조직에서 익숙하게 사용하는 점진적 변경 전략입니다.

우리의 이야기를 만들어가는 과정

늘 쓰는 도구들이 징검다리처럼 엮어주는 길 위로 자연스럽게 일을 합니다. 사실 Popit에 글을 올리는 일은 통상적인 직업 일상밖 일이라 할 수도 있습니다. 사실 필자가 한참 일을 배우던 시절 [3] 블로그는 일상 업무 기록의 도구였다는 특수성을 생각하면, 필자가 다른 동료의 개취 인정을 하던 태도가 스스로를 향한 결과인지도 모르겠습니다. 또한, 이러한 글이 동료들의 결과물에 미치는 영향은 미미하다 할 수 있습니다. 그러나, 우리에게 운이 따르고 우리가 함께 같은 길을 오래가기로 마음 먹고 살아간다면 행복한 순간과 풍부한 이야기를 만드는데 이 글 역시 일조할 수 있으리라 믿습니다. 그리고, 이 글을 동료들끼리 나누는 이야기로 두지 않고 공개적으로 쓰는 이유는 필자가 지칭한 우리라는 표현에는 아직 우리와 함께 하지 않는 미래의 일원이 있을 수도 있다고 믿기 때문입니다.
커머스 혹은 유통 도메인 설계에 대한 연작 (지난 글)
1편. 커머스 혹은 유통 도메인 설계에 대한 연작
2편. 상품 정보 관리 라이브사이클 정의
3편. 가격 할인 기능을 서비스로 바꿔보기
4편. 상품 정보 다룰 때 BoundedContext 와 엔터티
5편. 애그리게잇 하나에 리파지토리 하나

주석

[1] 동료에게 상태머신을 설명하는데 한참의 시간이 걸렸기에 독자들에게도 마땅히 그래야 할 테지만, 실제 읽고 궁금해하는 분이 없을 수도 있어 미리 설명하지 않습니다.
[2] Go 언어를 사용합니다.
[3] 소프트웨어 설계 컨설팅회사의 막내로 다니던 2003년부터 엠파스 블로그에서 블로깅 시작