--- 서론 ---

국비 끝내고 작은 서비스회사 들어온지 한 1년 되어가는데

이곳도 시니어급이라 할만한 초고수없이 맨땅에 부딪쳐가며 서비스를 만든 곳이라 코드가 옛스러움

lombok, 테스트코드, Optional, 람다 이런거 안씀

그래서 나도 이직준비차 공부도 할겸 친구랑 각잡고 사이드 프로젝트 하나 만들어보자! 해서 만드는 중인데,

이게 다른사람이 보면 별 대수롭지도 않은 내용일것같아서 질문하기가 쫌 무섭긴 한데.. 그래도 질문해볼게



--- 프로젝트 구조와 데이터 흐름 ---

일단 구조는 RestAPI로 쓸 부트 서버 하나, 그 앞단의 웹페이지를 보여줄 부트 서버 하나 이렇게 있는데

회원가입을 예로 들면


html + js에서 Controller에 요청 

-> 앞단 프로젝트 Controller에서 UserDTO에 담아 Service로 전달 

-> 앞단 프로젝트 Service에서 UserDTO를 gson.JsonObject로 바꿔서 API서버로 요청

-> APIController에서 데이터를 gson.JsonObject 형태로 받아 UserDTO로 바꿔서 Service로 전달

-> Service에서 Mapper를 통해 DB와 통신 후 결과값 역순으로 리턴


이런 식인데.. 각잡고 만들어보자 마음을 먹으니까 궁금한게 너무 많아졌어


--- 질문 ---

1. API와 통신을 할때, gson.JsonObject <-> XXXDTO간 전환을 어떻게 해야하는지? 

아니면 전환이 필요 없는지? 없다면 gson, jackson같은 라이브러리는 어떤 용도로 쓰는지?


DTO가 1개면 모를까 유저정보를 담는 DTO가 있을 것이고, 상품정보를 담는 DTO가 있을 것이고, 결제정보를 담을 DTO도 있을 것인데

각각의 DTO가 가지고 있는 변수가 다를텐데 String형태로 바꿔서 파싱을 해야하는건지,

그것도 아니면 뭔가 설정을 해두면 그냥 XXXDTO, YYYDTO 형태를 바로 떤져도 잘 넘어가지는지..

평소에 생각없이 원래 짜여져 있던대로 HashMap<String, Object> 형식으로 죄다 던지고 받았던지라 갑자기 이런거부터 턱 막히네..


2. 만약 API가 아닌 앞단 프로젝트의 Service에서 따로 비즈니스로직을 처리할게 없고, 

단지 API로 전송하는 역할만을 한다면, 그럼에도 불구하고 Controller -> Service를 거쳐 API와 통신해야 하는지, 

아니면 JS단에서 바로 API를 호출해도 되는건지, 그게 비권장사항이라면 이유가 무엇인지 궁금해


3. 패키지 트리를 어떤식으로 정리하는게 좋을지?

우리회사는 기능별로, 예를들어 main, company, user, item, book.. 이런식으로 패키지를 만들고 그 하위에 controller, service, mapper 패키지를 만들거든

그런데 친구네 회사는 가장 상위 패키지가 rest, web이고,

web 밑에는 controller 패키지 하나만 두고, 꼭 서버단에서 미리 만들어서 내려줘야하는 특수한 몇몇 경우를 제외하고는 순수 html 페이지를 호출하는 컨트롤러만 거기다가 둔다고 하네?

그리고 rest 밑에다가는 controller, service를 만들어서 API와 통신하고..

어떤게 더 좋은 방식인지 잘 모르겠어서 다른사람은 어떻게 생각하는지 궁금함


4. 비즈니스 로직을 어디에서 구현하는게 좋은 방법인지?

입력받은 데이터를 토대로 무언가를 계산하고, 암호화한 다음 DB에 넣어야한다. -> 앞단프로젝트의 Service

꺼낸 데이터를 복호화해서 무언가 계산한 뒤 내려줘야하는데, 이 API를 여러군데에서 호출하고, 모든 곳에서 동일하게 적용되는 로직이다 -> API프로젝트의 Service

꺼낸 데이터를 복호화해서 무언가 계산한 뒤 내려줘야하는데, 오직 한 프로젝트에서만 필요하다 -> API는 전달만 해주고 앞단프로젝트의 Service

내 생각이 맞는지 궁금함