[Coding Standard] Swagger 문서화 표준: 중복 없이 정확한 API 문서 만들기
API 문서가 코드와 어긋나는 순간, 문서는 없느니만 못한 것이 된다. 클라이언트 개발자는 문서를 믿고 구현했는데 실제 서버는 다르게 동작하기 때문이다. 그리고 이 어긋남은 대개 같은 정보를 두 군데에 적어놓고 한 쪽만 고쳤을 때 생긴다.
Coding Standard
[Coding Standard] Service 계층의 assert: 흐름을 드러내고 실패를 숨기지 않기
Service 메서드를 처음 여는 사람은 두 가지를 알고 싶어 한다. 이 메서드가 무엇을 전제하고 동작하는지, 그리고 어디까지 왔을 때 무엇이 보장되는지. 보통은 주석이 그 역할을 한다.
[Coding Standard] 계층별 검증 표준: 형식은 Controller, 규칙은 Service
@Valid 하나 붙이면 검증이 끝난다고 생각하기 쉽다. 그런데 실제로 코드를 열어보면 검증이 여러 군데에 흩어져 있다. CreateOrderRequest의 @NotBlank, OrderDomain 생성자의 Objects.requireNonNull, OrderEntity의 @Col...
[Coding Standard] 패키지 구조: 규칙을 컴파일러가 강제하게
지금까지 세운 표준들을 다시 읽어보면 같은 문장이 반복해서 나온다.
[Coding Standard] 계층별 DTO 네이밍 표준: Request부터 Domain까지
DTO 하나를 Controller부터 JPA Entity까지 그대로 끌고 다니는 구조는 편하다. 필드도 한 번만 정의하면 되고, 변환 코드도 안 짜도 된다. 문제는 편한 만큼 계층 사이의 의존성이 전부 한 클래스에 뭉친다는 것이다. Entity에 컬럼 하나를 추가하면 API 응답이...
[Coding Standard] 예외의 종류: 어디서 터지고 누구 잘못인가
예외 처리 표준에서 ErrorCode와 BusinessException으로 실패를 다루는 방법을 정했다. 그런데 그 글이 다룬 것은 우리가 직접 던지는 예외뿐이다.
[Coding Standard] 예외 처리 표준: 실패가 나가는 길을 하나로
지금까지 정리한 표준들은 요청이 들어오는 길을 다뤘다. 이 글은 반대 방향, 실패가 나가는 길을 다룬다.
[Coding Standard] DTO는 생성자로만 만든다: 상태가 완성되는 지점을 하나로
객체 하나가 어떤 상태로 만들어질 수 있는지 알아내려면 코드를 몇 군데나 봐야 할까. setter가 있는 DTO라면 답은 “전부”다. 어디서든 필드 하나를 바꿀 수 있으니, 이 객체의 가능한 상태를 알려면 이 타입을 쓰는 모든 코드를 확인해야 한다.
[Coding Standard] 애그리거트 경계: 무엇을 한 덩어리로 볼 것인가
패키지 구조 표준에서 “패키지가 애그리거트 경계 역할을 한다”고 적었다. 그런데 그 애그리거트를 어디서 끊을지는 정하지 않았다.
[Java] 상속 vs 합성: 실무에서 어떻게 선택할까?
“상속은 나쁘다”, “합성이 항상 우월하다”는 말을 자주 들어보셨나요? 하지만 실무에서는 이런 이분법적 사고가 오히려 비효율적일 수 있습니다. 이번 글에서는 상속(Inheritance)과 합성(Composition)을 실무에서 어떻게 선택하고 활용하는지, 실제 경험을 바탕으로 정리...
[Java] Assert로 프로그래머의 실수를 잡아내기
Java의 assert는 개발자들 사이에서 “있지만 거의 쓰지 않는” 기능으로 취급받습니다. 왜일까요?
[Java] Null-free 객체 설계와 생성 철학 정리
이번 글은 “애플리케이션 내부에는 null이 없다” 라는 전제에서 출발한다. 문자열/객체형은 null을 허용하지 않고, null이 가능한 경우에만 변수명에 orNull을 명시한다. 이 전제를 지키면 팀 내부 규칙이 아주 단순해진다.
[Java] 팩토리 메소드 패턴으로 Service 레이어 가독성 개선하기
비지니스 로직이 복잡해 지면서 Service 레이어의 코드가 복잡해지기 시작했습니다. 특히 DTO를 VO로 변환할 때 문제가 두드러졌습니다. 해당 문제는 로직의 가독성을 크게 떨어뜨렸습니다.