<aside>

</aside>

1. 프로젝트 구조

완벽한 DDD는 아니지만 최대한 사용하려고 노력 했습니다. (DDD Lite)

선정이유

1. 높은 응집도: User, Order, Item 등 관련된 기능 단위로 코드를 모아, 비즈니스 로직의 흐름을 한눈에 파악하고 유지보수하기 쉽게 설계했습니다.
2. 협업 효율성 증대: 팀원별로 담당 도메인을 나누어 개발할 때, 서로 다른 패키지에서 작업하게 되므로 Git 충돌 가능성을 최소화했습니다.
3. 확장성 고려: 추후 특정 도메인의 복잡도가 높아질 경우, 해당 도메인 패키지만 분리하여 마이크로서비스로 확장하기 용이한 구조를 지향했습니다.

인프라 설정의 버전 관리:docker-compose.yml, nginx.conf, deploy.sh 등 서버 배포 및 설정에 필요한 파일들을 Git으로 관리하기로 했습니다. 이를 통해 인프라 변경 이력을 추적하고, 서버 장애 시 빠르게 복구할 수 있는 환경을 구축했습니다.

📂 src/main/java/org/sopt/poti
 ┣ 📂 global          <-- [인프라 & 설정]
 ┃ ┣ 📂 auth          <-- Security, JWT
 ┃ ┣ 📂 common        <-- 공통 응답 (ApiResponse)
 ┃ ┣ 📂 config        <-- 설정 (Web, Swagger, QueryDSL, Security)
 ┃ ┣ 📂 error         <-- 예외 처리 (GlobalExceptionHandler)
 ┃ ┗ 📂 external      <-- S3, Discord 등 외부 연동
 ┃ 
 ┣ 📂 domain          <-- [비즈니스 로직] 기능별 분리
 ┃ ┣ 📂 user          
 ┃ ┃ ┣ 📂 controller
 ┃ ┃ ┣ 📂 service
 ┃ ┃ ┣ 📂 repository
 ┃ ┃ ┣ 📂 entity      <-- @Entity (JPA는 class 사용)
 ┃ ┃ ┗ 📂 dto         ****<-- Record 활용
 ┃ ┃ ┃ ┣ 📜 UserLoginRequest.java (record)
 ┃ ┃ ┃ ┗ 📜 UserInfoResponse.java (record)
 ┃ ┣ 📂 item          
 ┃ ┣ 📂 order
 ┃ ┗ 📂 review
 ┃
 ┗ 📜 PotiApplication.java

2. 공통 응답 규칙

모든 API 응답은 ResponseEntity에 ApiResponse 레코드를 담아서 반환하게끔 통일하여 클라이언트와의 혼선을 줄이려고 했습니다.

또한, ResponseEntity로는 status code를 기본적으로 사용하고, ApiResponse에는 프로젝트 자체 코드를 넣어 쉽게 트래킹 가능하게 만들었습니다.

public record ApiResponse<T>(
    int code,
    String message,
    T data
) {} 

3. ErrorStatus

서비스 내에서 발생하는 예외 상황을 ErrorStatus Enum으로 통합관리합니다.

하드코딩 방지와 유지보수성 향상에 이점을 가지고 있습니다.

public enum ErrorStatus {

  /**
   * 400 Bad Request
   */
  BAD_REQUEST(40000, HttpStatus.BAD_REQUEST, "잘못된 요청입니다."),

  /**
   * 401 Unauthorized
   */
  INVALID_TOKEN(40100, HttpStatus.UNAUTHORIZED, "유효하지 않은 토큰입니다."),

  /**
   * 404 Not Found
   */
  USER_NOT_FOUND(40400, HttpStatus.NOT_FOUND, "존재하지 않는 사용자입니다."),
  ITEM_NOT_FOUND(40401, HttpStatus.NOT_FOUND, "존재하지 않는 상품입니다."),

  /**
   * 500 Internal Server Error
   */
  INTERNAL_SERVER_ERROR(50000, HttpStatus.INTERNAL_SERVER_ERROR, "서버 내부 오류입니다.");

  private final int code;
  private final HttpStatus httpStatus;
  private final String message;
}

4. SuccessStatus

성공 코드를 활용하여 message를 잘못적는다던지, code를 잘못적어 보낸다던지 등 개발자의 실수를 줄이기 위해 도입했습니다.

public enum SuccessStatus {

  /**
   * 200 OK
   */
  // 공통
  OK(HttpStatus.OK, "요청이 성공했습니다."),

  /**
   * 201 CREATED
   */
  // 공통
  CREATED(HttpStatus.CREATED, "생성이 완료되었습니다.");

  private final HttpStatus httpStatus;
  private final String message;
}