서비스와 백그라운드 작업

UI 이벤트와 서비스 계층, 비동기 작업을 명확히 분리해 유지보수 가능한 앱을 만듭니다.

서비스 경계

비즈니스 로직은 클릭 핸들러 안에서 자라기 쉽지만, 그렇게 두면 테스트와 재사용이 어려워집니다. 화면은 사용자 의도를 서비스에 전달하고, 서비스는 결과와 실패 이유를 명확한 모델로 돌려주는 구조가 유지보수에 유리합니다.

- UI builder는 표시 책임에 집중합니다.

- 서비스는 화면에 필요한 record를 제공합니다.

- 외부 API 호출은 별도 adapter로 감쌉니다.

저장, 승인, 배포 같은 명령은 읽기 작업보다 실패 비용이 큽니다. 명령 요청 모델을 분리하고 권한, 검증, idempotency, 후속 이벤트를 같은 순서로 처리하면 장애 상황을 더 쉽게 설명할 수 있습니다.

- 명령 이름은 사용자 행동과 맞춥니다.

- 중복 제출을 서비스에서도 방어합니다.

- 성공 후 갱신할 화면 범위를 정합니다.

긴 작업은 UI 요청 안에서 끝내려 하지 말고 작업 상태를 조회 가능한 모델로 노출합니다. 사용자는 완료 여부보다 현재 진행 중인지, 실패했는지, 다시 시도할 수 있는지를 먼저 알아야 합니다.

- 작업 ID와 상태 enum을 둡니다.

- 재시도 가능 실패와 불가능 실패를 구분합니다.

- UI는 polling 또는 push 전략을 명확히 선택합니다.

서비스 로직은 화면에서 문제가 보일 때 원인을 추적할 수 있어야 합니다. 요청 ID, 사용자 ID, route, 명령 이름을 로그에 연결하면 프론트 증상과 서버 이벤트 사이의 거리가 줄어듭니다.

- 중요 명령에는 구조화 로그를 남깁니다.

- 사용자에게 보이는 오류 코드와 로그를 연결합니다.

- 배치 작업은 시작과 종료를 모두 기록합니다.