brunch

객체의 작명과 속성 부여 과정이 경계를 만드는 일입니다

어떻게 하면 모델링을 잘할 수 있을까?

by 안영회 습작

<모델링에서 행위자를 뽑는 일은 시스템 맥락을 만드는 일>에 이어서 계속해서 동료의 피드백을 살펴봅니다.


주차 요금 정산을 위해 마주해야 하는 대상은 차량이다

다소 모호한 표현이 등장합니다.

정산의 대상은 차량이다


아마도 정산하여 과금을 부가할 대상을 뜻하는 듯합니다. 여기서 <낱말의 뜻을 깊고 넓게 묻고 따지는 일의 소중함> 실천을 위해 한자사전을 찾습니다.

풀이를 보는데 문득 한국말로 '마주해야 할 대상'이라는 표현이 떠오릅니다. '마주한다'는 말은 꽤 마음에 드는 말입니다.


정확한 작명 노력이 객체의 경계와 정체성을 보여준다

정산이라는 말도 다소 모호한 감이 있어 풀어봅니다. 그림을 보면 주차면에 머문 시간을 기준으로 과금을 하는 것이란 점을 알 수 있습니다. 클래스도로 나타내 보려고 마음을 먹었더니 이내 가급적 영어 표현을 쓰려는 관성이 작동했습니다. 그래서, 퍼플렉시티에 질문을 하는 과정에서 프롬프트 수정을 하게 되었습니다. 그러는 과정에서 자연스럽게 모호한 생각에 갈래가 생기고 개념들이 조금씩 차려졌습니다.


먼저 차량 번호는 객체의 식별자로서는 유효하지만, 레코드의 PK(Primary Key)나 객체 식별값(id) 위주로 사고하는 흔적이라고 추정해 볼 수 있습니다. 하지만, 그 식별값을 통해 추출하는(derived) 다양한 속성과 특징을 함께 활용하는 것이 객체지향의 기본 전제입니다. 그래서 차라는 객체를 생각하는 편이 더 나은 접근입니다. 그런데 해당 도메인은 모든 차량을 다루는 것은 아니기 때문에 퍼플렉시티에게 이렇게 물었습니다.

주차장에서 주차료 부과 대상 차량을 칭하는 영문 이름을 제안해 주세요


무려 10개나 옵션을 주었는데, 첫 번째 이름인 Chargeable Vehicle을 쓰기로 합니다.


속성 부가는 객체의 내용과 경계 설정 활동이다

그리고, 필수적인 속성을 생각해 보겠습니다. 먼저 차량 번호가 있겠죠. 다음으로 정산을 위해 알고 있어야 할 시간들을 따져 보았습니다. 가장 먼저 입차시간과 출차시간이 있는데, 앞서 다룬 바대로 정산을 요청하는 시점에서 계산이 벌어질 수 있습니다. 고객 편의를 위한 고려죠.

그런데 여기서 이력에 대한 고려가 필요합니다. 특정 차량이 딱 한 번만 주차장에 올 수도 있지만, 사업이 흥하려면 자주 와야겠죠. 그렇다면 시각에 대한 기록은 하나의 변수에 담을 수가 없습니다. 레코드 관점에서 쓰는 말이지만, 이런 경우를 흔히 '이력 관리'라고 말합니다. 이력 관리는 사후 확인을 위해서도 필요하지만, 자주 이용한 사람들을 단골로 만들기 위한 마케팅 수단(쿠폰이나 마일리지 적용) 개발을 위해서도 요긴하게 쓰일 수 있습니다.


하지만, 이 글은 모델링을 다루는 글이니 이력은 별도의 객체에 담는다는 점만 분명하게 표기한 클래스도로 표현하기로 합니다.


정산에 관한 핵심 클래스와 속성을 찾아내기

계속해서 정산 관련한 클래스를 도출하기 위해 또다시 퍼플렉시티에게 작명 제안을 요구했습니다. 몇 차례 인공지능과의 묻따풀(혹은 질문 행위)로 참고할 만한 용어표가 생겼습니다.

그다음 클래스도를 그리는데 관계에 대한 생각이나 이벤트를 고려할 것인지 여부로 인해 생각이 복잡해졌습니다. 차분히 차려 가기 위해서 일단 관계에 대한 고려와 이벤트 따위는 무시하고 필요한 객체(혹은 클래스)를 표현하는 수준으로 단계를 좁혀서 실행합니다.

먼저 운전자나 차단기 앞 직원에 의해 정산 실행을 요청한 시점에서 과금을 한다는 전제 아래 입차시각부터 흐른 시간을 기준으로 계산(caluate)한다고 가정했습니다. 이때, 주차장 이용료에 대한 규칙, 요금표, 기준(Price Table, Rate 따위)이 있을 텐데 이를 Parking Fee에 담습니다. 개념적 수준에서 캡슐화를 실천한 것이라고도 볼 수 있습니다. 이어서 영수증을 출력하는 오퍼레이션을 추가했다가 지웠습니다. 일단, 사용자가 지불을 이행하기 이전까지만 담아 보는 것으로 단계를 좁혔기 때문이죠.


모델링은 사고의 과정을 다루기 때문에 차분하게 생각을 따져 물을 수 있도록 단계적으로 접근하는 것이 효과적입니다. 그렇기 때문에 이번에 어디까지 할 것인지를 분명히 하는 편이 좋습니다. 전에 동료에게 조언했던 말을 <모델을 그리기 전에 '생각의 종이'부터 준비하세요>라는 글에 담은 적이 있는데, 일맥상통하는 말입니다.


글이 길어져 다음 내용은 별도의 글로 이어갑니다.


지난 어떻게 하면 모델링을 잘할 수 있을까? 연재

(26회 이후 링크만 표시합니다.)

26. 모듈화: 다시 쓰는 동시에 유연성을 줄 수 있나?

27. 자기 조직화를 소프트웨어에 구현할 수 있는가?

28. UML 혹은 객체지향 관계 중 합성과 집합의 차이

29. 상태 관리에 대한 이해가 필요한 비대칭 분산 시스템

30. 복잡한 클래스를 엮어서 단순한 복합체를 만드는 OCP

31. 사건을 포착하여 객체로 만드는 이벤트에 대한 설명

32. UI 디자이너가 만든 기획서로 객체 지향 모델링하기

33. Domain-driven 업무 소통: 업무를 객체로

34. ECB 패턴과 2025년의 실효성 해석

35. 사건 발생을 이벤트 정의와 발행으로 모방하기

36. 사건이라는 개념을 프로그래밍 이벤트로 응용하기

37. 프로그래밍에서 이벤트는 모듈화를 위해 도입한 개념

38. 사용자 경험과 연결되는 도메인 이벤트 설계 품질

39. 커피숍에서 우연히 만난 도메인 이벤트 대응 사례

40. 입차와 출차를 바탕으로 객체 설계의 꽃인 상태도 활용

41. 주요 비즈니스 상태에서 도메인 이벤트를 식별하기

42. 모델링에서 행위자를 뽑는 일은 시스템 맥락을 만드는 일

43. 비동기 호출과 이벤트 기반 프로그래밍의 연결

keyword
작가의 이전글비동기 호출과 이벤트 기반 프로그래밍의 연결