9개 문서가 "Backend" 태그에 분류되었습니다

프론트엔드에는 대응물이 없는 문제, 살아 있는 데이터 위에서 스키마를 바꾸는 일 — 마이그레이션 도구의 changelog(커밋 히스토리)와 baseline(스쿼시 스냅샷), 그리고 변경 이력을 자동으로 남기는 audit 테이블까지 정리합니다.

인바운드/아웃바운드 어댑터를 가르는 기준은 데이터의 방향이 아니라 호출의 방향입니다. 이벤트 리스너와 fetch, props 콜백에 대응시켜 의존성 규칙과 의존성 역전(DIP)까지 풀어봅니다.

부분 수정 API에서 null 필드의 오래된 모호함 — JSON Merge Patch, JSON Patch, 필드 마스크까지 업계의 해법들을 비교하고, 바꿀 필드를 명시하는 permit 계약과 필드 단위 검증 패턴을 프론트엔드의 dirty fields에 대응시켜 봅니다.

API 응답을 도메인 모델에 맞출 것인가, 독립적으로 설계할 것인가 — 규칙이 아니라 트레이드오프입니다. 경계마다 옷을 갈아입는 DTO 레이어링과, 필드 전파를 컴파일러에게 맡기는 인터페이스 구현 강제까지 다룹니다.

검증 로직 하나를 두고 모델·서비스·컨트롤러 사이에서 고민해 본 경험으로 풀어보는 로직의 자리 — rich/anemic 도메인 모델의 스펙트럼, 도메인 서비스와 애플리케이션 서비스의 구분, 그리고 권한이 사는 곳.

헥사고날 아키텍처가 모델을 중심에 놓는 이유를 프론트엔드 개발자의 언어로 풀어봅니다. React 코어와 렌더러의 관계로 이해하는 포트와 어댑터, 그리고 요청 하나가 레이어를 지나가는 길.

ktlint는 Prettier, detekt는 ESLint, Gradle 멀티모듈은 pnpm workspace — 백엔드 온보딩에서 만난 도구들을 FE 대응물로 정리하고, 대응물이 없는 도구는 왜 없는지까지 짚습니다. FE→BE 온보딩 시리즈의 마지막 글입니다.

같은 도메인의 API라도 호출자가 누구냐에 따라 퍼블릭·오퍼레이션·인터널로 나뉩니다. 인터널 API의 경계는 왜 네트워크가 아니라 도메인 사이에 그어지는지, 권한은 왜 퍼블릭에만 거는지를 다룹니다.

"컬럼 추가는 비싸다"는 이제 옛말입니다. 현대 DB에서 개별 컬럼과 JSON 컬럼을 가르는 진짜 판단 기준 세 가지 — DB가 그 필드를 알아야 하는가, 민감정보 묶음인가, 백필 비용은 어느 쪽이 싼가 — 를 정리합니다.