아장아장거리면서 주책부리는 블로그

값타입과 불변객체 값타입은 안전하고 단순하게 다룰 수 있어야 한다. 하지만, 값타입을 공유참조하며 문제가 생긴다. 임베디드 타입을 여러 엔티티에서 공유할 경우 부작용이 발생할 수 있다. 그렇기에 불변객체로 설계하는 방식을 사용한다. 불변객체란, 객체 타입을 수정할 수 없게 만들어 부작용을 원천 차단하는 방식이다. Constructor이후에 Setter를 통해 객체를 수정할 수 없게 사용하는 방식이다. 우아한 테크코스에서 Setter를 사용하지 않고 객체를 만들어 쓰라고 했던 기억이 있다. 이래서 그런건가 싶기도 하다. 값타입 컬렉션 값타입 컬렉션을 DB에 구현하는게 쉽지 않다. 컬렉션 자체를 테이블에 담는게 관계형 데이터베이스에 바로 넣기보단, 다른 테이블에 담아주어야 한다. 컬렉션을 구성하는 데이터로 ..

JPA에서는 데이터 타입을 두가지로 만들어 저장한다. 엔티티 타입 데이터가 변해도 식별자로 계속 확인 가능. 데이터의 인스턴스가 변경되어도 식별자를 통해 이게 무슨 데이터인지 알 수 있다. 예) 나이를 먹어도 나이를 보고 아 이게 나이구나 라고 알 수 있다. 값 타입 Int, String처럼 단순값으로 사용되는 타입이나 객체 식별자가 없고 값만 있기 때문에 변경시 추적 불가능하다. 예) 26(하 2023년이제 이제...)을 보고 이게 나이인지(물론 난 알지) 뭔지 알 수 없다. 오늘 공부해본 값 타입에는 3가지가 존재한다. 기본값 타입(java에서 기본으로 제공해 사용할 수 있는 타입) 임베디드 타입(복합 값) 컬렉션 타입 (임베디드와 컬렉션은 JPA에서 설정해서 사용해야 한다. ) 기본값 타입 Stri..

Member라는 엔티티에서 이루어지는 도메인 로직에 대한 테스트들을 만들었다. 이 테스트를 정상적으로 수행하기 위한 코드를 만들어보아야 겠다. Member라는 도메인 로직을 짜면서 추가적으로 고민했던 부분은, 다른 도메인과 엮여 사용되어 다른 도메인, 다른 기능에 종속적이지 않게 하려고 했다. 외부에서 Member에 대한 데이터를 변경하는 기능을 수행하는 경우를 만들지 않도록, 도메인 내에서 모든 로직을 만들려고 했다. 이러한 점을 토대로, 회원가입 / 정보 수정 / 비밀번호 변경 기간 만기여부 확인의 기능을 만들었다. 회원가입 일단 회원가입 로직부터 정리를 해보았다. 일단 필요한 경우는 이메일 형식이 올바르지 않으면 예외처리 비밀번호 2번 입력이 서로 일치하지 않으면 예외처리 예외가 없다면 인스턴스 초..

Member에 대한 테스트를 만들어보아야 겠다. 일단, Member 생성자에 RegisterRequestDto를 넣을 것이다. 그러기 위해, 테스트를 위한 RegisterRequestDto를 생성하주자. private RegisterRequestDto makeTestRegister(){ return new RegisterRequestDto("username", "nickname", "email@email.com" , "password", "password"); } AllArgsConstructor로 모든 인스턴스를 넣은 Dto를 만들었다. 이를 @Builder를 이용해 조금 더 깔끔하게 만들어보았다. @AllArgsConstructor @Data @Builder public class RegisterRe..

이전에 멤버에 대한 구상을 해둔 상태이다. 이에 맞는 멤버를 만들어보아야 겠다. @Entity @Data @AllArgsConstructor @NoArgsConstructor @Builder public class Member extends BaseEntity { @Column(name = "MEMBER_USERNAME") private String username; @Column(name = "MEMBER_NICKNAME") private String nickname; @Column(name = "MEMBER_EMAIL") private String email; @Column(name = "MEMBER_PASSWORD") private String password; @Column(name = "MEMB..

DAO DAO(Data Access Object) 는 데이터베이스의 data에 접근하기 위한 객체이며, DataBase에 접근 하기 위한 로직 & 비지니스 로직을 분리하기 위해 사용한다. 현재까지 사용한 DAO는 Entity(데이터베이스에 저장되는 형태) 밖에 없는 것 같다. DTO DTO(Data Transfer Object) 는 계층 간 데이터 교환을 하기 위해 사용하는 객체로, DTO는 로직을 가지지 않는 순수한 데이터 객체이다. 생성자와 getter정도만 쓰는 것 같다. DTO는 DAO가 그대로 외부에 나갈 때, 안전하지 않을 위험이 있기 때문에 사용한다고 이야기를 듣고 사용하다가, 이번에 어떤 용도인지 알게 되었다. 또한, 기능적 로직을 가지지 않게 해야겠다는 생각도 든다. VO VO(Value..

기본적인 설정들은 어느정도 만들어두었다. 모든 로직들을 만들고, 이에 대한 테스트 및 정리들을 해볼까 한다. 일단 회원부터 가지고 있어야 할 인스턴스들과, 로직들을 생각해봐야 한다. 회원 엔티티 인스턴스들 아이디(username) 닉네임(nickname) 이메일 비밀번호 역할 가입일자(BaseTimeEntity에 추가된다) 최근 수정일자(BaseTimeEntity에 추가된다. 수정일자가 1달이 넘으면 비밀번호 변경 요청을 보낸다) 기능 회원가입 로그인 닉네임 수정 비밀번호 수정 이메일 수정 비밀번호 변경 요청여부 확인 이러한 기능들을, 데이터베이스를 사용하지 않고 Member라는 도메인에서 사용할 수 있는 로직들로 어떤 부분들이 필요할지 생각해보아야 한다. 최소단위의 기능 회원정보를 가져오면 Member..

모든 엔티티에 공통적으로 쓰이는 부분들을 만들어두어야겠다. 일단, 기본적으로 데이터베이스에 들어가기 위해서는 모든 테이블에 id라는 속성이 존재한다. 또한, 생성일자, 수정일자를 등록해서 사용하려고 한다. 생성, 수정일자의 경우에는 사용자 : 비밀번호 최종 수정일자를 확인해, 수정일자를 기준으로 일정 기간이 지나면 비밀번호 재설정을 요청하는 알림을 추가한다. 게시물 : 게시물 작성일자를 추가하고, 수정되었을 경우, 수정됨을 알릴 수 있다. 댓글 : 게시물과 마찬가지로 작성일자, 수정일자를 추가한다. 메시지 : 카톡과 마찬가지로, 보내진 시간등을 설정해둘 수 있다. 이렇게 다양하게 쓰이기 때문에, BaseEntity로 설정해, 모든 엔티티에서 추가적으로 id, createdTime, updatedTime을..

일단, 필터를 만들어서 우리가 해야할 일을 알아야 한다. 토큰을 받아왔을 때, "Authorization"으로 되어있는 헤더를 가져온다. 이 헤더에 대한 인증 방식이 우리의 토큰과 같을 경우, 토큰 부분을 떼고 나머지를 가져온다. 이 부분이 사용 가능한 토큰인 경우, 사용자의 인증정보를 Authentication에 담아주면 된다. 이러한 동작을 필터에서 만들어주면 된다. 일단, 토큰을 받아왔을 때 필요한 부분만을 가져와주는 동작을 만들었다. private String resolveToken(HttpServletRequest request) { String bearerToken = request.getHeader(AUTHORIZATION_HEADER); if (StringUtils.hasText(beare..

Token Provider에서 토큰의 서명, 토큰 자체의 문제에 대한 예외를 처리하거나, 토큰의 지원여부와 만료여부에 대한 예외도 처리했다. 그런데도 처리해야할게 남았다. 뭘까...? 생각해보면,우리가 보낸 예외처리에 대해 어떻게 반응해야 할지 처리를 안했다. 이전에 만들었던 validateToken부분에서는 모든 예외를 받아와 이를 로그로 출력시키는 과정을 만들어두었다. 그렇다면, 사용자에게 해당 예외에 대해 어떻게 처리할지 알아야 한다. (AuthenticationEntryPoint) 또한, 이 때는 토큰에 문제가 있을 경우에만 처리가 되었으며, 토큰에 문제가 없는데 토큰에 있는 사용자의 권한상 해당 요청을 할 수 없을 경우 이를 처리해주어야 한다. (예를 들면, 사용자가 관리자 페이지를 가면 곤란해..