마이크로서비스로 가기 전 모듈형 모놀리스로 시작하려고 합니다. 팀이 실제로 지킬 수 있는 경계를 어디까지 두는 게 적절할지 고민 중입니다.
현재 생각한 구조
community → membership → access-control
content → engagement → notification커뮤니티 승인처럼 여러 모듈을 함께 변경해야 하는 흐름은 애플리케이션 서비스에서 조율하고, 외부로 나가는 변경만 Outbox 이벤트로 전달하려 합니다.
경계가 코드 구조에만 있고 테스트로 강제되지 않으면 금방 무너질 것 같다는 게 가장 큰 걱정입니다.
비슷한 규모의 팀에서 잘 작동한 기준이나, 오히려 너무 잘게 나눠서 불편했던 경험이 있다면 듣고 싶습니다.
댓글 14
처음부터 패키지별 public API를 정하고 ArchUnit으로 역참조를 막는 방식이 가장 오래 버텼어요. 이벤트는 필요한 곳에서만 쓰고, 같은 트랜잭션이 필요한 흐름은 억지로 분리하지 않았습니다.
ArchUnit 규칙을 너무 세밀하게 만들면 리팩터링 때 부담이 되지는 않았나요? 모듈 간 DTO를 어디에 두셨는지도 궁금합니다.
public API를 각 모듈 루트에 두는 방식부터 시도해보겠습니다. 경계를 어기는 경우를 테스트로 보여주는 게 팀 합의에도 도움이 되겠네요.
배포 단위가 아니라 변경 이유가 같은 것끼리 먼저 묶어보세요. 커뮤니티와 멤버십은 분리된 모듈이어도 승인 트랜잭션은 애플리케이션 서비스 하나가 조율할 수 있습니다.