-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PR 답변 모음 #160
Comments
음.. 이때는 한번 더 다시 찾아서 주는게 정확하다고 생각했었는데, 어차피 save후 다시 Select해서 돌려주는 것이여서라 49라인에서 리턴하면 될것 같습니다. |
안그래도 버전 문제 때문에 조금 고생 했었는데 앞으로 여기서 있는지 먼저 확인해 봐야겠습니다. 감사합니다! |
-1. 변경 되는 부분은.. 안 그래도 좀 걱정되기는 했는데 Member MS 쪽에서 이벤트를 발행 해주면 그걸 구독해서 변경을 해야되지 않을까 생각했습니다. 동기로 구현시 서버의 리소스를 갑자기 많이 쓸 수도 있을거 같아서 나중에 카프카로 구현해 볼 수 있을 것 같습니다. -2. 좋아요 리스트 n+1이슈도 있고해서 네이티브 쿼리로 가져올까 했었는데 이 부분을 염려해서 말씀 주신건지 궁금합니다. |
이 부분은 멘토링때도 언급 주셔서, 시나리오 단위로 PR 해보려고 합니다! |
아 이 부분은 처음에는 UpdatedAt과 CreatedAt이 같다가 바뀌기에 PostEntity의 @UpdatedAt 어노테이션을 없애지만 않으면 null일 경우가 없기는 합니다. 그렇지만 혹시 변경이 생길수도 있기에 널일수도 있다고 표시하기위해 추가하였습니다. 음.. 어쩌면 이부분은 인프라의 로직이 도메인에 침투해 있는 것일 수도 있겠다는 생각이 조금 들기는 합니다. |
-1. 테스트 컨테이너 버전 -2. schema.sql 실행 -3. connection factory 관련 JPA에서 쓰듯이 application.yml의 url에 미리 스키마를 써두면 자동으로 스키마를 만들어 주지 않아서 접속 자체에 문제가 생기고, 스키마를 안쓰면 연결은 되는데 SQL파일의 'USE SNS' 부분이 작동하지 않아 스키마를 지정해서 쓸수가 없었습니다. 그래서 첫번째 연결때의 factory는 initializer에서만 사용하고 빈등록한 factory를 연결용으로 쓰려고 시도해 보았습니다. |
저도 반신반의 하면서 해보았습니다. 그런데 테스트 코드를 만들어 보니 동작은 합니다! 그래서 이 방법으로 선택 했었는데, 인프라의 리포지토리와 도메인의 리포지토리를 구분해서 쓰는 지금 방식이 훨씬 편해서 좋은것 같습니다. |
아무래도 도메인 서비스가 길어지는 것에대해 부담이 생겨서 차선책으로 생각했었는데, 응용계층은 비즈니스로직을 보다는 트랜잭션이나 다른 에그리거트 루트와의 소통을 담당하는게 맞는 것같아 여기에 DTO를 두면 응집도가 떨어질것 같다는 생각이 듭니다. 음.. 만약에 길어진다면, 내부 클래스들은 같은 도메인의 디렉토리에 두지만, DTO를 각각의 파일이나, 하나의 묶어놓은 파일로 분리를 하면 될까요? |
No description provided.
The text was updated successfully, but these errors were encountered: