아키텍처·

flex·2주 전

경계를 빌드로 못 박으면, 경계를 옮기는 일도 빌드가 붙잡습니다

Gradle 모듈로 도메인 경계를 물리적으로 못 박았을 때 생기는 역설을 짚는 글이다. 잘못된 의존을 컴파일러가 막아주는 그 메커니즘이, 나중에 경계를 다시 그릴 때는 발목을 잡는다.

핵심 포인트

모듈 분리는 잘못된 의존을 빌드 단계에서 차단해주지만 그 경계를 옮기는 비용도 같이 올린다
초기에 독립적으로 보이던 두 도메인이 늘 함께 바뀐다면, 합치는 작업이 모듈 지형 전체를 다시 그리는 공사가 된다
확신이 없으면 덜 쪼갠다 — 하나를 둘로 나누는 비용이 둘을 하나로 합치는 비용보다 싸다
경계 기준은 코드의 외형이 아니라 함께 바뀌는 리듬으로 잡는다
경계 조정을 기능 개발과 동급의 정상 작업으로 취급한다

상세 정리

문제 상황: 설계 시점에는 분리돼 보였던 도메인이 실제로는 항상 같이 변경되는 경우가 생긴다
비용 구조: 이때 클래스를 옮기는 정도로 끝날 리팩터링이 모듈 의존 그래프 전체를 손보는 일로 커진다
대응 1: 경계 확신이 낮은 구간은 물리 분리를 미루고 논리적 구분만 유지한다
대응 2: 변경 이력을 근거로 함께 바뀌는 단위를 찾아 그 단위로 경계를 맞춘다
대응 3: 구조 개선을 별도 승인이 필요한 예외 작업이 아니라 일상 작업 흐름에 넣는다
적용 범위: 도메인이 안정적이고 오래 유지할 코드베이스에 맞는 접근이다

왜 읽나멀티 모듈로 아키텍처를 강제하려는 팀에게, 그 선택이 되돌리기 어려워지는 지점과 완화책을 미리 알려준다.

flex 블로그

원문은 여기서 이어서 읽을 수 있어요

읽음 (0)

·takedown 요청

이 글과 비슷한