그냥공부

개발 간단함deloy도 간단하다 \-- smaller teams and applications 에서 !! --Fewer cross-cutting concerns\-- security,logging,auditing 등등 single place 에서 관리하니깐--perfo

userDetatils 구현한 org.srpingframework.security.core.userdetails.User를 보자보면이렇게 구현되어 있다.userDetails를 implement 할라면getAuthorities()를 구현해야 되는데이부분이 잘 이해가 안갔

서버 한대 띄우면 상관없는데여러대 띄우면 스케줄러코드가 동시에 작동한다..!profile 로 해결하기application-cron.yaml 만들고설정정보 넣어준다음(선택일듯)classes level 이나 method level 에다가@Profile("cron") 해주면

현재 상황은

프로젝트 하던중에 게시판을 만들어야 했다post 테이블과 postComment 테이블이 있고Comment 는 다음과 같다댓글 그리고 대댓글만 제공하기로 하였고replyCommentId는 값이 없으면 부모댓글(depth=0)값이 있으면 자식댓글(depth=1)이다이때 애

유저대 클럽 N:1 관계이고클럽을 삭제할라면 그 클럽의 주인(클럽을 만든사람)이여야만 가능한 서비스 로직이다그래서 기존의 코드는 다음과 같은데..이 부분이 너무 거슬려서 어떻게 뺄 수 없나.. 그리고 클럽장인지 확인하는 로직은 이부분말고도 많은 클럽과 의존하고 있는 모

글 요약은 jpaRepository에서 지원하는 메소드들은대부분 @Transactional이 붙어있다.영속성컨텍스트에서 변경사항이 감지되면 쓰기 지연 저장소에 저장되어있다가commit할 때나 실제 쿼리가 나가게 된다.이다.Member와 Post를 만들어주기리포지토리는서

이 주제는 사실 인터넷에 검색하면 엄청많이 나온다 그리고 매우 유명한 topic이라고 하더라 근데 내가 몰랐었다 아.. 그래서 다른 분들의 글을 부분부분 옮겨적는 수준에 불과한 글이다 참고자료들은 밑에 링크를 달아두었다 AOP 참고자료 https://gmoon

Command Query Responsibility Segregation 의 약자이다.명령과 조회 라는 책임으로 분리하겠다는 뜻CRUD의 CUD가 명령에 해당하고R는 조회에 해당애플리케이션이 데이터를 다루는데 있어서는 특정 모델로써 다루어진다고 한다.(예를 들어 "구매

분산환경에서Command성 서비스는(create/update/delete) aggregates 들로 묶이는 경우가 많다.이때 saga에 참여하는 것들은 하나의 트랜잭션 단위로 묶여서 데이터의 정합성을 보장해야 하는 경우가 많다.전통적으로 two phase commit을