왜 필요한가
기능들이 서로의 내부를 건드리지만 서비스를 나누면 운영 부담이 커집니다. 한 배포 단위 안에서 경계를 세울 필요가 있습니다.
어떻게 해결하는가
- 가상 독서 앱: 한 팀, 앱 v1에 카탈로그·보관함·결제 포함. A17은 태그 없음.
- 보관함 소유 테이블에 태그 저장을 추가하고 앱 v2를 배포합니다. 결제 동작은 그대로입니다. 데이터베이스는 하나지만 테이블은 모듈별 소유, 다른 모듈의 직접 접근은 금지합니다.
- 보관함이 카탈로그 API를 프로세스 내부에서 호출한 뒤
travel을 기록합니다. 조회 실패 시 태그 없음 유지, 복구 후 재시도.
설명을 위한 가상 예시
내부 계약, 공동 배포
독서 앱 · 한 팀 · A17은 태그 없음
변경: 보관함 태그 추가. 결제 동작은 그대로.
배포 단위 · 1
앱 v1 → 앱 v2카탈로그
API문서 조회소유한 내부 구현카탈로그 소유 테이블보관함
태그 기능 추가APIA17 태그 설정: travel소유한 내부 구현보관함 소유 테이블 + 태그 필드결제
API동작 유지소유한 내부 구현결제 소유 테이블
보관함 → 카탈로그 API · 프로세스 내부 호출
다른 모듈 테이블에 직접 접근 금지. 호출은 해당 모듈 API를 통과.
공유 데이터베이스 하나, 테이블 소유권은 분리. 보관함 저장 변경도 공동 배포에 포함.
- 조회 성공 → travel 기록 → A17 태그는 travel.
- 쓰기 전 조회 실패 → 태그 없음. 실패 안내, 복구 후 재시도.
모놀리스의 한 유형: 배포와 프로세스 장애 공유. 코드 규칙·검사로 API 경계를 강제해야 하며 폴더만으로는 보호되지 않습니다.
소유권 상자는 접근 규칙을 뜻하며 데이터베이스 서버 수를 뜻하지 않습니다.
무엇이라 부르는가
모듈러 모놀리스는 하나의 배포 안에 명시적인 내부 경계를 둡니다. 모듈 API가 소유한 내부 구현을 보호합니다. 여전히 모놀리스입니다. Fowler
폴더 구분 이상의 경계 강제가 필요하며 배포·프로세스 장애는 공유합니다. 모듈 내부에 헥사고날 포트를 둘 수 있습니다.
이 선택에 관한 이야기
세 언어가 댓글을 공유합니다. 작성하려면 GitHub 로그인이 필요합니다.