같은 단어를 쓰면 같은 개념인 줄 알았다

처음엔 기록이라는 단어가 하나면 충분해 보였습니다.

진행 중인 기록도 기록이고, 끝난 기록도 기록이고, 보여주는 카드도 기록이었습니다.
이름을 나누면 괜히 복잡해 보였습니다.
초기 제품에서는 그 단순함이 꽤 편했습니다.

문제는 세 번째 맥락이 들어온 날 시작됐습니다.

같은 단어를 쓰는 세 개념이 서로 다른 규칙을 요구했습니다.

이름이 같아서 더 늦게 알아챘습니다

처음엔 타입을 합치고 싶었습니다.

필드가 비슷했습니다.
ID도 비슷했고, 화면에서 보이는 값도 비슷했습니다.
그래서 하나의 모델로 처리하면 빠를 것 같았습니다.

하지만 시간이 지나자 이상한 조건문이 늘었습니다.

if active:
if archived:
if displayOnly:
if ownerMode:

처음엔 자연스러운 분기라고 생각했습니다.
제품이 커지면 조건이 생기니까요.
그런데 어느 순간 조건문이 도메인 개념을 대신하고 있었습니다.

진행 중 이벤트와 완료된 기록은 lifecycle이 달랐습니다.
표시용 문자열과 코드 심볼은 변경 가능성이 달랐습니다.
역할, 권한, 행동 모드는 같이 움직이는 것처럼 보였지만 실제로는 다른 축이었습니다.

같아 보이는 걸 같은 것으로 취급한 비용이었습니다.

단순하게 시작한다는 말을 오해했습니다

“단순하게 시작하라”는 말은 맞습니다.

근데 이 말을 “개념을 섞어도 된다”로 오해하면 나중에 비쌉니다.
기능을 적게 만드는 건 단순한 시작입니다.
서로 다른 개념을 하나의 이름에 밀어 넣는 건 빚입니다.

처음엔 그 차이가 잘 안 보입니다.

역할이 두 개뿐이면 정체성, 권한, 행동이 같이 움직입니다.
그래서 하나의 enum으로 충분해 보입니다.
그런데 세 번째 역할이 들어오면 깨집니다.
어떤 사람은 권한은 A인데 행동 모드는 B여야 합니다.
그때부터 enum 이름이 거짓말을 합니다.

제가 지금 찾는 신호

도메인 모델이 뭉쳐 있다는 신호는 꽤 비슷했습니다.

신호	의심
같은 타입에 mode, kind, status가 계속 추가됨	개념이 섞였을 수 있음
특정 화면에서만 쓰는 필드가 모델에 붙음	표시 객체와 도메인 객체가 섞임
if role == X && action == Y가 반복됨	역할과 행동 축이 섞임
이름은 같은데 변경 규칙이 다름	별도 객체일 가능성

이 신호가 보이면 바로 거대한 리팩터를 하지는 않습니다.
먼저 용어를 나눕니다.

진행 중 이벤트.

완료된 기록.

표시 카드.

권한 역할.

행동 모드.

못생긴 이름이어도 괜찮습니다.
같은 단어 하나로 모든 걸 덮는 것보다 낫습니다.

분해는 코드보다 먼저 말에서 시작됐습니다

제가 배운 건 도메인 모델링이 타입 파일에서 시작되지 않는다는 점입니다.
말에서 시작됩니다.

팀이 같은 단어로 서로 다른 것을 말하고 있으면 코드도 결국 그렇게 됩니다.
문서에 같은 용어가 여러 의미로 나오면 API도 흔들립니다.

그래서 요즘은 구현 전에 이런 질문을 적습니다.

이 단어가 가리키는 lifecycle은 하나인가?
권한 규칙이 같은가?
표시 문자열을 바꿔도 API가 깨지지 않는가?
사용자 데이터와 참조 데이터의 소유자가 같은가?

네 개 중 하나라도 애매하면 분리 후보입니다.

분리하면 초기에 파일이 늘어납니다.
이게 싫어서 계속 미루고 싶어집니다.
저도 그랬습니다.

하지만 나중에 DB 마이그레이션, API 버전, 클라이언트 분기를 동시에 고치는 것보다 낫습니다.

같은 단어는 편합니다.

편한 이름이 정확한 모델은 아니었습니다.