Context와 컴포넌트와 이상적인 아키텍처
도메인 모델링 세미나 13
<맥락은 어떻게 표현할 것인가?>편에서 다루었던 주제에 대해 아래 결과물을 만든 동료의 회고가 있었다.
Context의 쓰임새
그는 Context의 쓰임새를 아래와 같이 정의했다.
누구나 대화를 할 때 자기 머릿속에 있는 생각과 느낌을 바탕으로 한다. 그런데 그걸 명시적으로 드러내지 않으면 서로 다른 암묵적 맥락(context)을 갖고 대화할 가능성이 높다. 내가 <성공적 대화를 돕는 그림>이란 것을 개발한 이유도 같은 이치다.
적어도 업무적인 대화를 한다면, 사전 준비와 대화 중의 행동에 대해 훈련을 통해 이를 개선할 수 있다.
대화가 아니라 모델링의 효과를 높이려 할 때로 살짝 바꿔보면 동료가 정리한 Context의 쓰임새가 바로 그 답(정답이 아니라 그의 답)에 해당한다고 할 수 있다.
해당 개체의 중심에 무엇이 있느냐?
나는 지난 글에서 시간을 때울 때 축구 콘텐츠에서 영감을 받은 이야기를 한 바 있다. 그때 캡처했던 다른 장면도 통섭적으로 써먹을 수 있는 기회란 생각에 인용한다.
출처: 이스타TV위 캡처에서도 이분법적인 관점이 등장한다. 그러나 둘 중 하나를 택일하는 식보다는 포트폴리오 구성 측면의 이야기다. A와 B의 두 가지 방법을 소개하면서 둘 중 하나만 택할 수도 있지만, 동시에 두 방법을 다 쓰는데 비중이 어디가 크냐 하는 식의 이야기니까.
나는 이때 'A와 B의 초점은 무엇이지' 하는 질문을 하게 되었다. 정확하게 이런 문장의 질문은 아니라 말로 표현하자니 정확하게 표현을 못할 듯해서 보완하는 비슷한 질문을 몇 개 더 써본다.
모호한 상황에서 구심점을 어떻게 찾지?
표현의 중심에 둘 가치 혹은 본질적인 가치는 어떻게 정하지?
나는 지난 글에서 시스템의 문제는 이해관계자와 그들의 욕망으로 좁혀서 표현한 바 있다. 연쇄적으로 관련 있는 또 다른 기억이 꼬리를 물고 뒤따른다.
지수지원 프로젝트의 기억
2007년에 증권거래소에서 지수(Index)를 관리하는 지수지원시스템 차세대 프로젝트에 참여한 일이 있다. 이때 개별 주식에 해당하는 종목의 분류에 대해 궁금증이 생겨 아래와 같은 질문을 한 일이 있다.
어떤 종목이 지칭하는 회사가 두 가지 산업에서 비슷한 매출을 하면 종목 분류를 어떻게 정하나요?
당시의 도메인 전문가는 내게 지수관련위원회(정확한 명칭은 기억이 나지 않는다)에서 정한다는 명쾌한 답을 해줬다. 그렇다. 인간의 시스템이니 인간이 정하지. :)
컴포넌트는 어떤 기준으로 정하나요?
이렇게 과거의 기억을 반추했더니 다시 <아키텍처 그림 가운데 있는 데이터>편에서 인용한 질문에 대해 다르게 설명할 수 있다. 내가 경험적으로 그린 아래 그림에서 경계를 나눈 혹은 컴포넌트를 나눈 기준은 객관적 언어로 설명할 수는 없었다.
그런데 그 기준과 개체의 중심에 무엇이 있나 하는 나의 즉흥적 질문은 일맥상통하는 듯하다. 설계자가 컴포넌트 혹은 하나의 단위로 정한 덩어리가 있다. 이는 임의적이다. 공론화를 통해 객관성을 얻을 수 있지만, 사람이 인위적으로 만든 구분이다. 그리고, 소프트웨어는 그 본질이 바로 인위적 산물이란 특징을 갖는다.
그렇게 정하고 나서 스스로 핵심 가치를 부여한다. 소프트웨어 공학에서는 책임(Responsibility)이라고 부르기도 하는 바로 그것이다. 그것이 분명하면 해당 컴포넌트가 응집성(cohesion)을 갖고 수정하기 쉬운 코드 상태를 유지할 수 있다. 나는 앞서 이를 <아주 이상적인 아키텍처>라 명명한 일이 있다.
맺음말
생각의 흐름에 따라 쓴 글이라 주제가 다소 모호하지만, 제목으로 주제를 표현하고 여기서 마친다. :)
지난 도메인 모델링 세미나 연재
5. 아주 이상적인 아키텍처
10. Repository 빌딩 블록에 대해 생각해보기
11. 맥락은 어떻게 표현할 것인가?
