모델을 개발하는 리포지토리(?)
도메인 모델링 세미나 24
모델링 업무를 다루는 동료에게 두레이 업무 작명 규칙에 대한 조언을 하면서 '이건, 소프트웨어 모델링에도 유용하네' 하는 생각이 들어 (CLOVA 노트로) 메모했던 내용을 글로 바꾼다.
서브젝트를 객체로 만들기
서브젝트라는 영어 단어를 썼지만, 엄격한 정의가 아니라 말 습관에 따른 것이다. 실상은 문제 영역의 모호한 상태의 덩어리를 지칭한 것이다. 모호한 덩어리에서 객체를 추출하는 일이 모델러의 일상 활동이다.
<개체(시스템)의 재설계와 경계의 변경> 편에서 '개체를 규정하는 일과 경계'란 글에서 비슷한 내용을 글로 쓴 바 있다.
구름이나 진흙처럼 모호한 상태에서 경계가 분명하게 객체가 규정지어진다는 말은 객체가 아닌 부분과의 관계도 드러난다는 뜻이다.
결국 객체의 정의는 다른 객체나 환경과의 관계를 정의한다는 말이기도 하다.
협업의 맥락
아래 대화를 하면서 상대가 있어서 생각이 정리된다는 점을 활용했다. 그래서, 내가 하는 말을 내가 음성 메모하는 낯선 행위가 꽤 유용하다는 사실을 배웠다. 아무튼 이 방법을 통해서 나는 평소 믿고 있었지만 표현하지 못했던 암묵지를 꺼낼 수 있었다.
나는 개발자 시절 익힌 TDD와 이슈 트래커로 배운 협업 방식을 개발자가 아닌 사람까지 넓혀 보려고 두레이를 쓰고 있다는 사실을 깨달았다. 개발자가 아닌 사람도 유기적으로 대화하면서 발전시킬 수 있는 일종의 지식의 리포지토리를 갖는 일이 필요하다.
리포지토리는 정돈된 형태로만 존재하지 않는다
대화와 상호작용이 만들어주는 힘에 나는 또 놀랐다. Repository에 대해서 한 번도 도달해보지 못한 이해의 공간에 도착했기 때문이다. :)
그런데 도서관과 같이 오랜 시간 정비된 리포지토리가 아니라 나 혹은 우리 팀을 위한 리포지토리를 위해서는 동선을 관찰하고 루틴으로 만들어가야 한다. 기업에 오래 계신 분들은 '프로세스'라는 단어와 '루틴'을 확고하게 구분하지만 가만 보면 범주의 문제일 뿐 둘은 같은 내용이다.
객체를 개발하는 리포지토리
음성 메모를 정리한 글을 쓰고 나서 독자들을 위한 최소한의 예의로 이 글의 취지를 제목에 붙여 보았다. 처음에는 <객체를 개발하는 리포지토리>라고 지었다. <서브젝트를 객체로 만들기>라는 소제목과 <리포지토리는 정돈된 형태로만 존재하지 않는다>라는 소제목을 엮어서 대충 조합한 것이다.
그런데, 리포지토리는 현재 동료의 진도에 따르면, 객체 자체보다는 모델을 담고 있는 상태다. 이 글은 동료의 연구에 발맞춰 쓰고 있기 때문에 객체 대신에 모델 리포지토리로 바꾸기로 한다.
지난 도메인 모델링 세미나 연재
5. 아주 이상적인 아키텍처
10. Repository 빌딩 블록에 대해 생각해보기
11. 맥락은 어떻게 표현할 것인가?
18. 도메인 모델링 절차에 대하여
19. 왜 도메인 모델링을 하는가?
