Topic
API 설계
명확한 계약, 인증과 권한 경계, 검증과 실용적인 HTTP API 의사결정을 다룹니다.
'마이' 도메인 없이 마이페이지 데이터를 조합하는 법
사용자, 주문, 상품의 책임은 각 도메인에 유지하면서 전용 조합 계층으로 마이페이지 요약 데이터를 만드는 방법을 설명합니다.
불필요한 조회 없이 권한 검증을 설계하는 법
로그인 사용자를 한 번만 확인하고 접근 검증의 책임을 좁히며, 시스템 관리자와 채널 단위 권한을 구분하는 설계.
'마이'는 왜 도메인이 아닌가
마이페이지는 클라이언트가 보는 화면이지 비즈니스 도메인이 아닙니다. 주문, 상품, 쿠폰은 원래 주인에게 두고 경계에서 조합합니다.
회원과 비회원을 함께 다루는 조회 모델
공개 리액션 수와 회원별 상태를 하나의 조회 흐름으로 반환하되, 선택적 사용자 정보와 필수 인증의 경계는 분명히 나눈다.
UI 모양을 넘어서는 도메인 모델 설계
트리 모양의 API가 트리 모양의 도메인을 요구하지는 않습니다. 클라이언트 계약은 프레젠테이션 경계에 두고 내부 개념을 조합해 응답합니다.
변경 비용으로 나누는 클라이언트와 서버의 책임
표시 전용 처리는 UI 가까이에 두되, 여러 클라이언트와 배포된 앱 버전 때문에 변경이 비싸다면 의미 있는 값을 서버에 모으는 기준입니다.
REST 순수성보다 명확한 API를 설계하라
REST의 장점은 활용하되 클라이언트의 이해, 팀의 일관성, 도메인 경계와 변경 비용을 기준으로 HTTP 계약을 결정하는 방법입니다.
경계에서 검증하고 핵심 흐름은 단순하게
API 입력을 프레젠테이션 경계에서 온전한 비즈니스 값으로 바꾸고, 널을 안쪽에 넘기지 않으며, 저장 데이터는 들어올 때 검증하는 방법입니다.
API 요청 모델을 핵심 도메인에서 분리하라
프레젠테이션 경계에서 외부 요청을 비즈니스가 소유한 값으로 바꿔 API는 안쪽을 의존하고 코어는 바깥을 모르도록 만드는 방법입니다.
플랫폼 API에서 제공자 식별과 인증 경계를 나누는 법
작은 플랫폼 API가 제공자 키를 도메인 식별자로 바꾸고 데이터를 구분하며, 규모에 맞는 인증 경계를 선택하는 과정을 다룹니다.
계층마다 DTO를 습관처럼 만들지 마세요
데이터가 서로 다른 계약을 가진 경계를 넘을 때 DTO를 사용합니다. 매핑에도 비용이 들지만 외부 요청 형태가 서비스 내부를 지배하게 두는 데도 비용이 듭니다.