피드로 돌아가기
Building EDIFlow - Infrastructure Layer: Parsers, Repositories & Data Packages (Part 4)
Dev.toDev.to
Backend

표준별 독립 패키지 설계와 Pipeline 패턴을 통한 EDI 파싱 구조 최적화

Building EDIFlow - Infrastructure Layer: Parsers, Repositories & Data Packages (Part 4)

hello-ediflow2026년 5월 7일10intermediate

Context

EDIFACT, X12 등 서로 다른 구분자와 엔벨로프 구조를 가진 다중 표준을 단일 인프라 계층에서 처리 시 발생하는 낮은 응집도 문제 분석. 모든 표준 정의를 한곳에 통합할 경우 불필요한 의존성 증가와 거대 패키지(God-package) 생성 위험 존재.

Technical Solution

  • 표준별로 @ediflow/edifact, @ediflow/x12와 같이 인프라 패키지를 분리하여 구현체 간 의존성 완전 차단
  • 공통 기능인 파일 로딩 및 캐싱을 위해 @ediflow/infrastructure-shared 패키지를 도입한 계층적 의존성 그래프 설계
  • Delimiter Detection → Tokenization → Segment Parsing으로 이어지는 Pipeline 패턴 적용을 통해 각 단계의 독립적 테스트 및 확장성 확보
  • UNA 서비스 문자열 기반의 동적 구분자 검출 로직을 구현하여 비표준 파트너사의 다양한 구분자 요구사항 대응
  • Repository 패턴과 Lazy Loading을 결합하여 대규모 JSON 메시지 정의 파일의 로딩 오버헤드 제어
  • Builder 패턴을 활용해 각 표준별 검증 규칙을 캡슐화함으로써 Core 레이어의 표준 불가지론적(Agnostic) 상태 유지

1. 다중 표준 지원 시 구현체 간 직접 참조를 금지하고 인터페이스 기반의 의존성 역전(DIP)이 적용되었는가?

2. 파싱 과정이 단일 거대 함수가 아닌 단계별 Pipeline 클래스로 분리되어 단위 테스트가 가능한 구조인가?

3. 사용자에게 불필요한 데이터 정의가 전달되지 않도록 표준별 데이터 패키지를 분리하여 배포하고 있는가?

4. 빈번하게 참조되는 대용량 설정 파일에 대해 Lazy Loading 및 Caching 전략이 수립되었는가?

원문 읽기