본문 바로가기
개인 공부용/crud.jpa.api

튜터님의 피드백

by pon9 2024. 12. 17.

1. DDD에서의 domain은 repository 등 다른 파일에 의존하지 않아야 한다. DDD를 사용하기보단 3-Layer Architecture도 공부할 거리가 많으니 사용해봐라. DDD는 domain내부에서만 상호작용 해야한다. service검증로직(validtate) 등은 repository가 아닌 user객체로 진행해라. (하지만, DDD 본것중에 거의 제일 잘 썼다 < 자랑임 ㅋㅋ)

 

2. get요청에 대한 캐시메모리는 기본적으로 브라우저에서 지원하므로 cache를 사용하는것은 비효율적이다. 거기다, cache를 남용하면 비용이 엄청나다. 기본적으로 redis를 사용하는 이유는 매우 빨라서이고, 단순 cache에 국한되기보다는 다양한 시스템에 많이 사용될 수 있다.

메모리에 관한 공부가 필요하다. '운영체제' 책을 추천한다. 매일 한 두장이라도 읽으면, 쌓이는 것이 있을 것이다.

백엔드개발자는 단순히 spring을 배우는 것이 아닌 cpu와 메모리, 스레드 등을 효율적으로 사용하는 것을 배워야 한다.

 

3. queryDSL은 업데이트가 느리고 자잘한 에러도 많으니 JOOQ를 사용해봐라. 단, 초기설정이 queryDSL보다 까다롭다.

 

4. Httpservletrequest는 controller에서만 처리해야 한다. controller에서 service로 정보를 줄 땐 user 등 도메인 객체를 활용해라.

 

5. read count Async의 문제점: a사용자와 b사용자가 동시에 read를 하면, a사용자가 간발의 차로 먼저 read를 했다고 가정하자.

a사용자의 read과정이 먼저 처리되어서 view가 +1이 될것이지만, b사용자의 처리과정에 a사용자의 read count가 반영되지 않은 상태일 것이다.

해결방안

-> update쿼리문 활용(쉬움)

-> batch queue 이용하여 count 업데이트 - > redis 이용해보자. queue로 처리하면 아래의 그림과 같은 형태로 메모리가 처리될것이다.

0.5초로 설정하면 이런느낌?

 

6. paging 로직을 합치는 것이 유지보수성 측면에서 좋을 것이다. 지금은 너무 나뉘어있다.

 

 

 

원래오늘 테스트코드 작성해보려 했는데 이것부터 다 처리하고 해야겠다 ㅎ