출근
✨ 설계 목표
- Notification 시스템을 전처리 → 전송 → 후처리 3단계로 구조화
- 각 단계 내부는 복수의 Worker 처리 단위로 조립 가능하게 설계
- 재사용성, 유연성, 타입 안정성을 모두 만족시키는 구조를 고민
🔧 최종 구조 요약
Noticefication: 전체 프로세스의 실행자 (Orchestrator)NotiHandler<T, U>: 전처리, 전송, 후처리 각각의 전략 추상화NotiWorker<T, U>: Handler 내부에서 순차 실행되는 유닛 (Pipeline Step)- 흐름:
Payload → Message → SendResult → PostResult순으로 전달
💡 주요 설계 포인트
1. Handler 내부에 Worker 조립 방식 채택 (Pipeline Pattern)
- JSON 변환, 암호화, 값 조정 등 다양한 전처리 로직을 동적으로 조합 가능
action(input, previousResult)구조로 이전 결과값을 다음 단계에 전달
2. 전략 + 파이프라인 패턴의 혼합 사용
- 각 단계는 Strategy로 캡슐화
- 내부는 파이프라인으로 구성 → 구조화된 유연성 확보
3. Map에 넣고 싶던 유혹… 하지만 타협 NO
- 타입 추적과 역할 분리를 끝까지 밀고 가며, Context 구조나 DTO 기반으로 설계 유지
- 실무에서는 절반만 써도 되지만, 지금은 정공법을 택함
⚠️ 고민했던 부분
- Worker가
input만 받을지,input + result를 받을지 → 후자를 채택 - 전략 vs 파이프라인의 경계가 애매해질 위험성 → 역할 주석과 책임 명확화로 해결
📚 회고
“간단한 설계도 실제로 구현해보면 이렇게 복잡해진다.
하지만 그 복잡함을 하나하나 구조화해서 감당해 나가는 경험이
실무에서 감각적으로 의사결정하는 힘으로 남을 것이다.”
🧭 다음 단계 (Optional)
NotiHandler를 명확한 역할명으로 리네이밍 (ex.PipelineStage)ProcessingContext도입 여부 실험- 블로그 포스팅 + UML 다이어그램 추가
