경계 찾기
주문, 결제, 알림처럼 변경 이유와 데이터 소유권이 다른 영역을 서비스 후보로 본다.
컨트롤러가 많다고 나누는 것은 아니다
소유권 경계
주문, 결제, 알림처럼 데이터 책임이 갈리는 지점을 먼저
나눈다
통신 계약
transport, schema, timeout, retry를 소비자 변경까지 고려해
고정한다
운영 추적
request id, health, queue lag로 실패가 어디서 멈췄는지
연결한다
통신 방식 선택
즉시 응답이 필요하면 동기 호출, 느슨한 결합과 비동기 처리가 필요하면 메시징을 검토한다.
transport 선택은 장애 전파 방식도 바꾼다계약 고정
DTO, proto, event schema, version을 명시하고 소비자가 깨지지 않게 변경한다.
내부 타입을 그대로 노출하지 않는다실패 흐름 작성
timeout, 재시도, 중복 메시지, 부분 실패, 보상 처리를 서비스별로 둔다.
네트워크 경계는 항상 실패할 수 있다관측 연결
request id, trace, service health, queue lag를 이어서 장애 지점을 찾게 한다.
분산 구조는 로그가 연결되어야 운영된다Monolith
단일 배포와 단순 트랜잭션
팀과 도메인이 작고 강한 일관성이 필요하면 먼저 단일 앱이
낫다.
초기 복잡도를 줄인다
Sync call
즉시 결과 필요
사용자 요청 안에서 결과가 필요한 조회와 검증에 맞지만 장애
전파를 조심한다.
deadline을 둔다
Event
비동기 후속 처리
알림, 로그, 검색 색인처럼 나중에 처리해도 되는 작업에
적합하다.
중복 처리와 순서를 설계한다
Data ownership
DB 경계
서비스별 데이터 소유권을 분리하지 않으면 분산 모놀리스가
된다.
공유 DB는 결합을 남긴다