24.09.12 TIL - 프로젝트 하면서 배운 팁

오늘 배운 것

• 패키지 구조
• Service에서 어떤 것 호출하는지
• application.yml 파일 분리

 

패키지 구조

이전에 프로젝트를 진행할 때 패키지 구조를 각 엔티티별로 나눴다. 

 

각 엔티티 패키지가 있고 해당 패키지 안에 controller, service, repository 패키지 등이 있는 구조였다. 

 

이렇게 나눈 이유는 각자 맡은 도메인별로 개발을 진행했기 때문이였다. 

 

그리고 이전에 다른 프로젝트를 진행할 때 Controller나 Dto 등이 너무 많아지면 한 패키지에서 찾기 어려웠다. 

 

그래서 각 도메인별로 모아두는 것이 보기 편해서 이렇게 진행하였다. 

 

아래 그림처럼 Dto가 너무 많아 찾기가 어려웠다. 

 

 

그런데 패키지 구조를 도메인 별로 나누는 것보다 계층별로 나누는 것이 좋다고 한다. 

 

왜냐하면 도메인별로 나누면 ServiceController에서 ProductController로 찾아가려면 계층을 올라가서 찾아야 하기 때문에 찾기 어렵다고 한다. 

 

그리고 패키지가 굉장히 많아지는 문제도 있는 것 같다.

 

그래서 아래처럼 계층별로 controller 패키지, service 패키지... 이렇게 만들라는 것이다. 

 

 

그렇다면 위의 Dto 패키지 사진처럼 Dto가 굉장히 많아지는 경우는 어떻게 해야 하는가?

 

이럴 때에는 Dto 패키지 안에 도메인별 패키지를 만들면 된다고 한다. 

 

예를 들어 User 관련 Dto가 많아지면 Dto 패키지 안에 User 패키지를 만들어 모아두는 것이다. 

 

이렇게 되면 Dto에서 User 관련 Dto를 찾으려고 하면 쉽게 찾을 수 있을 것이다. 

 

또한 패키지 안에 도메인으로 묶을만큼 많지 않은 경우 바로 찾을 수 있어 좋을 것이다.

 

 

 

Service에서 어떤 것 호출하는지?

이전 프로젝트에서는 각 Service에서 여러 Repository들을 필드로 가지고 있어 주입 받아 사용했다. 

 

늘 controller → service → repository 이 흐름에 익숙해지다보니 당연히 Service에서는 Repository를 가지고 호출해야 한다고 생각했다.

 

ProductService에서도 StoreRepository를 가지고 있는 것을 볼 수 있다. 

 

하지만 이렇게 Service에서 다른 여러 Repository를 가지고 있는 것보다 다른 Service를 가지고 다른 서비스 도메인 로직을 불러오는 것이 좋다고 한다.

 

왜 그런가 하면 이유는 아래와 같다. 

• 공통 작성 로직이 줄어든다. 
  • Repository에서 Product를 찾아온다면 각 메서드마다 예를 들어 .orElseThrow()하는 예외 처리 로직을 똑같이 작성해야 한다. 
• 다른 Service에서 작성해 놓은 로직을 사용할 수 있다. 
  • Repository에서 Product를 찾아온다면 예를 들어 is_delete 필드가 false인 Product만 가져와야 한다면 이런 로직도 Product 가져오는 모든 메서드에 똑같이 작성해야 한다. 

 

Service를 사용하면 이런 공통 작성 로직 없이 서비스 메서드 호출만으로 해결할 수 있다. 

 

그래서 Service에서 다른 Repository말고 다른 Service를 주입 받아 사용하라는 것이다. 

 

 

application.yml 파일 분리

이전 프로젝트를 진행할 때에는 설정 파일을 관련된 것끼리 분리해 놨다. 

 

예를 들어 email 관련 설정, DB 관련 설정... 이런 식으로 각각 application.properties를 사용했다. 

 

그리고 application.properties에서 include해서 사용했다. 

 

왜 이런 식으로 했는가 하면 db나 email 관련 설정에 노출되면 안되는 password나 key 값이 들어가는 경우가 있다.

 

이런 값들을 github에 올리지 않기 위해 설정 파일을 따로 분리해 놓고 gitignore 파일에 작성했다. 

 

 

그런데 개발 환경과 배포 환경을 분리할 때 어려움이 있었다. 

 

처음에는 개발 환경과 배포 환경에 다른 값이 DB 설정만 있다고 생각했다. 

 

그래서 remotedb와 localdb를 만들고 배포할 때 application.properties에 include에 값을 바꿔 넣었다. 

 

 

직접 바꿔 넣는 것이 번거로워 알아보니 JAR 파일 실행할 때 명령어로 설정 파일을 변경할 수 있었다. 

 

아래 명령어로 변경할 수 있다. 

java -jar "빌드된 Jar 파일명" --spring.profiles.active=dev

 

그리고 application.properties에 아래와 같이 작성했다. 

 

개발 환경과 배포 환경에 다른 값이 DB 설정만 있다고 생각해 dev와 prod에 DB 설정을 넣어 주었다. 

 

그런데 소셜 로그인할 때 url도 개발 환경과 배포 환경에서 달라졌다. 

 

관련된 것끼리 설정 파일 분리하고 싶은데 이것들을 또 어떻게 개발 환경과 배포 환경에서 다르게 처리할 수 있을지 고민이 되었다. 

 

차라리 active에 dev, devdb, devgoogle 이렇게 여러 개 설정한 것이 한번에 적용되면 좋겠다 싶었다. 

 

이렇게 여러 개 작성하면 여러 개의 설정 파일이 우선 순위에 따라 순차적으로 적용된다고 한다. 

 

 

그래서 해결책으로 생각한 것은 아래와 같다. 

• 개발, 배포 환경에서 공통적인 것들은 application.yml에 몰아 넣기
• 개발, 배포 환경에서 공통적인 것인데 노출되지 말아야 하는 것은 따로 빼서 include 하기
• 개발, 배포 환경에서 다른 것은 dev와 prod로 설정 나누기 
• 개발, 배포 환경에서 다른 것에서 노출되지 말아야 하는 것은 다른 여러 방법 사용해보기
  • dev, prod 설정 파일을 gitignore에 추가해 github에 올리지 않기
  • 암호화 하기
  • 환경 변수 사용하기 
  • .....

개발, 배포 환경에서 다른 것들 중 노출되지 말아야 하는 것들에 대한 여러 방법은 좀 더 알아본 후 작성해 보겠다. 

 

우선 개발, 배포 환경 설정 파일 분리는 아래와 같이 application.yml과 application-dev.yml로만 나눈 것이다. 

 

배포 시점에 application-prod.yml을 추가할 예정이다.

 

한번에 모아두는 것이 보기 불편하지 않을까 싶었는데 공통적인 것은 application.yml에 모아두는 것이 나을 것 같다. 

 

그리고 개발, 배포 환경에서 다른 것도 dev, prod 파일에 모아두는 것이 좋은 것 같다. 

 

 

 

마지막으로 설정 파일로 application.properties보다 application.yml을 많이 사용한다고 한다. 

 

실무에서도 yml을 많이 사용하고 계층적으로 볼 수 있어 편하다고 한다. 

 

간단한 어플리케이션에서는 properties를 사용하는데 복잡한 구성이 필요한 어플리케이션은 yml을 많이 사용한다고 한다. 

 

늘 spring에서 기본으로 properties를 제공해서 yml은 이전에 사용하던 것인줄 알았는데 아니였다.