기술 스택 정의

Java

• 17
• 현재, 자바 LTS 버전 중에서 8 다음으로 긴 Java Support 기간을 갖는다.
  • 추후, 상위 버전이 나오게 되었을 때, 자바 8 → 상위 버전으로 전환 하는 것보다, 17 → 상위 버전으로 전환 하는 것이 훨씬 수월할 것으로 예상된다.
  • 하위호환 잘 되는데 굳이 낮은버전으로 할 필요가 없다.
• allArgsConstructor, getter, equals & hashcode, toString 메서드를 컴파일러가 자동 생성 해줌
  • 새로운 필드가 추가될 때마다, 위 메서드를 수정해야 함
  • 롬복을 사용할 수 있지만, 파라미터 관련 이슈로 인해, @AllArgsConstructor를 사용하기에는 무리가 있음.
• 17 버전의 record class 기능이 DTO로 사용하는데에 큰 이점이 있다고 생각한다.
• 아래에서 이야기 할, 스프링 프레임워크 3.x 버전 이상부터는 자마 17이 필수적이다.

프레임 워크

• SpringBoot 3.1.1
• 프로그램 제어(의존성, 객체의 생명 주기 등)를 신경쓰기 보단, 도메인 문제를 해결하는데에 더 많은 시간(?)을 쏟을 수 있기 때문에 스프링 프레임워크를 사용한다.
• 스프링부트 2.7 버전의 오픈 소스 지원 기간이 23년 11월에 끝난다.
  • 추후, 버그 발견시에도 반영되지 않음을 뜻함
• 현재 공식 릴리즈 버전 중, 가장 최신 버전을 택함.

DB

• H2 -> MySQL -> 필요에 따라 단계별로 이관하기
• 사실, H2 혹은 MySQL은 우리에게 익숙하기 때문에 우선시 고려되는 점이 있다.
  • 초기 개발 단계에서는 H2를 사용하되, 추후 논의를 통해 RDB를 선정할 예정
    • RDB 선택 시 결정 이유 확실히 하기 (MySQL, MariaDB, …)

테스트

• JUnit5
• AssertJ
• RestAssured
• Mockito
• Java 진영에서 많이 사용되어 트러블 슈팅이 쉽고, 우리에게 익숙해 학습 곡선이 상대적으로 낮은 기술들을 선택하였다.
• Mocito의 경우 슬라이스 테스트의 필요성이 있을 때 사용 예정

그 외

• JPA
  • 객체 지향과 RDB간의 패러다임 불일치를 해소하기 위해 사용한다.
    • 패러다임 불일치를 해소하기 위해 복잡한 쿼리문을 작성하는 등 부가적인 작업이 필요함
  • 단순 CRUD 기능을 위한 쿼리문에 집중하기 보다는, 비즈니스 문제를 해결하는데에 더 많은 시간을 투자할 수 있음
  • Entity에 새로운 필드가 추가되는 경우 즉, 확장에 용이함 (쿼리문을 수정할 필요가 없기 때문에)
• Lombok
  • getter 등 여러 메서드들을 클래스 내에 작성하게 되면, 코드의 양이 증가하게 되고 이로인해 가독성 저하가 우려됨.
  • 사용하되, 파라미터 관련 이슈 로 인해 사용 규칙이 필요함. (All, required 는 파라미터 순서로 인한 문제를 야기함)
  • @Builder, @Getter, @NoArgsConstructor(대신 접근제어자 protected) 만 사용하기

API 문서화

• RestDocs
• 프로덕션 코드에 영향을 끼치지 않는다.
  • 테스트 코드가 통과되어야 하기때문에, 반강제적(?)으로 테스트의 양이 증가할 수 있음 (다다익선 !)
    • 실제 프로덕션 코드가 정상 동작되는지 확인하기 위해서는 여러 테스트를 거쳐야 한다고 생각.
• 추후 고도화 때 swagger처럼 문서에서 테스트가능하게 적용 예정