2024-01-08

주말과 오늘 진행한 내용은 다음과 같다.

1. 주말동안 진행하면서 팀원들과 프로젝트를 진행하면서 막혔던 부분에 대해서 의논한 내용을 정리한 글 

 

01/06 Code Convention 대한 의견정리 

안건1 : 객체지향의 5가지 원칙중 의존 역전 원칙 코드 컨벤션 추가 설정함!

1. User of(String email, String password…),
2. User of(UserCreateRequest) entity는 request에 의존하지 않고 그 자체로 존재해야 한다고 생각함

Request.toEntity(User) → User of(String email, String password…)

이 부분의 이후 문제점을 발견, Sequence 같은 경우 request가 필요하지 않는데 이것을 통일화하기 위해서는 SequenceRequest를 만들어야 하는데 불필요한 request dto인데 맞는 것 인가?

→ 하지만, 한 팀원의 의견(익명성 보장)은 굳이 entity를 생성하는 부분에서 이 request를 파라미터로 전달하는 부분이 꼭 모든 부분에서 통일화가 되어야 하는가? request를 전달하는 방식을 사용하자는 것은 개발의 편의성, 변경 가능성을 고려해서 적절한 방식을 혼용해서 사용하는 것이 어떤가입니다.

→ 이 request를 파라미터로 전달하는 방식과 필드를 파라미터로 전달하는 방식을 혼용해서 사용하는 것이 코드 내 통일성(= 컨벤션)을 위배하는 것인가? 에 대한 의견이 궁금합니다. → 저는 코딩 컨벤션이라는게 entity의 생성방식을 고정하는 것은 아니라고 생각하는데..

 

결론: 위의 의견에 대해서 튜터님은 정정펙토리 방식이 아닌 Request에 toEntity라는 해당하는 Request의 Entity를 생성할 수 있는 메서드를 사용해서 Entity가 Request에 의존하는 것이 아닌 Request가 Entity를 의존하게끔 하는게 좋다고 하셨다.

 

안건2 : Project Directory 구조에 대한 정리

goods(공연), sequence(회차), 좌석(seat), 공연장(place) 가 너무 depth 가 깊지않게 구성하고 싶은데 service나 controller가 작성되지 않더라도 패키지 분리가 좋을까요? 아니면 place → seat , goods → sequence 이런식으로 하위로 넣어주는 것이 명확할까요

 

결론:  프로젝트 기획상 분리하는것이 맞다고 판단됨

 

안건3 : Entity와 Dto의 변수 Type을 참조형으로 사용할지 아니면 원시타입으로 사용할지에 대한 의논

Long, User 참조형 타입 @ColumnDefault가 설정되어도 새로운 row insert할 때 default값이 들어가는것이아니라, null 로 들어가는데, long int 같이 primitive 타입이 아니라 기본 초기세팅 값 (0을 넣는 것이니깐, int long 같은 경우는 초기 세팅 값 0이라서 )

이유는 → 기본적으로 insert할 때, 객체의 모든 필드에 대해서 insert하기 때문에 null로 insert가 됨

@DynamicInsert, @DynamicUpdate 를 붙이면, null을 제외하고 row가 추가됨

공연 추가와 경매 추가 에 대한 고민

 

결론: 튜터님은 Entity에서의 필드값은 유지보수 및 사용적 측면으로 봤을때 참조형이 더 좋을것 같다고 하셨다.

 

안건4: 경매 남은 시간 처리에 대한 아이디어

1. 좌석 추가 시, 경매 등록(DB에)
2. redis 에 key(경매 id), value(해당 경매에 대한 입찰가) 남은 시간 등록(현재 ~ 경매 종료될 때까지의 시간) TTL
3. 유저들이 좌석을 선택
4. 웹 소켓을 여는데, STOMP 방식(채팅방 처럼), 1번 좌석을 선택한 모든 유저들을 하나의 채팅방에 초대하는 형식
5. 여기서 redis에 저장된 남은 시간을 뿌려줌
6. 경매 종료 == redis 에 키가 expire됨
7. 키에 대해서 listener를 두고 계속 체크
8. 이제 키가 없어지면, 경매 종료를 호출

결론: 아이디어 자체에서 문제점은 없음 따라서 좋은아이디어!

 

 

01/07

안건1: 예외처리진행시 Spring에 등록돼있는 메서드는 Overrided를 사용해서 Custom하는것이 좋은가? 

• 예외 처리 핸들러 구현에서, 모든 예외에 대해 작성하는 것이 아니라 ResponseEntityExceptionHandler 추상 클래스에 정의되어 있는 예외들은 오버라이딩 하자

결론: Spring에 정리돼 있는 Exception 메서드는  @Overried 해서 사용하는것이 좋다. 즉 있는건 사용하자.

 

안건2: 회원가입시 휴대폰 인증에 대한 안건

• 휴대폰 인증 시점
  1. ✅ 선 인증(인증 번호 발송 시, 핸드폰 중복 여부 검증 → 회원 가입 버튼 누른 후, 인증 번호에 대한 검증)
  2. 가입 시, 인증 번호와 휴대폰 번호에 대해 같이 인증(후 인증)

결론: 1번 방식을 채택하여 진행 결정

 

안건3: 프로젝트 구조상 동시성 처리를 위해 사용할 수 있는 다양한 방식중 낙관적 락은 좋은 방법인가?

• @Version(낙관적 락) → 동시에 접근하는 트랜잭션이 두 개 있다면, 먼저 접근해서 성공한 트랜잭션이 version을 올려주고, 이후에 늦은 트랜잭션은 버전을 확인하고 실패 처리됨

결론: 프로젝트를 진행하면서 동시성을 처리할 수 있는 방법들에 대해 진행해보고 추후 결정

 

2. 오늘 한 진행한 내용는 다음과 같다.

S3Config, S3Upload 추가 및 AWS 그룹 사용자 추가를 진행했다. 본격적으로 S3, EC2등 여러가지 Cloud를 사용할 것이기때문에 나의 AWS에서 그룹을 생성하여 팀원들의 사용자를 추가하여 자유롭게 사용할 수 있겠금 진행했다.

AWS의 그룹을 추가하기 위해선 IAM으로 접속하여 그룹을 생성하고 그룹에 관련된 정책 관련 설정을 해주면 된다.

AdministatorAccess가 그룹에 초대된 사용자에 대한 권한 승인에 관련된 정이고, 그 아래에 해당하는 권한은 해당하는 Cloud의 모든 권한을 허가하는 정책이다.

그룹을 생성한 후에는 사용자로 넘어가서 오른쪽의 사용자 생성을 누르고

다음과 같이 사용자 설정을 하고 다음을 누르면 된다. 만약 설정단계에서 사용자의 비밀번호를 지정하고 싶다면 자용자 지정 암호를 설정하면 된다. 하지만 어차피 자동생성된 암호를 누르면 알아서 다음에 해당하는 URL로 로그인할때 암호를 재설정하기 때문에 그냥 자동 생성된 암호를 사용해도 무방하다.

생성한 그룹에 추가를 한 후에 추가할 그룹을 체크하고 사진에는 없지만 보고 있는 화면에서 아래의 다음버튼으로 이동한다. 

마지막으로 아래의 사진의 페이지에서 사용자 생성을 추가하면 그룹에 초대가 마무리된다. 

 

이후에는 1번의 글에서 정리했던  안건들에 대해서 수정할 부분을 수정을 진행했다.

수정한부분은 기존에 Entity가 Request에 의존하던 부분을 변경하여 Entity에서 사용하던 생성자에 @Builder를 추가하여

Request에 ToEntity에 대한 메서드를 생성했다. 아래의 코드 블럭은 대표적 예시이다.

 

Request

import java.time.LocalDateTime;

import com.fasterxml.jackson.annotation.JsonFormat;
import com.sparta.ticketauction.domain.goods.entity.Goods;
import com.sparta.ticketauction.domain.sequence.entity.Sequence;

import jakarta.validation.constraints.NotBlank;
import jakarta.validation.constraints.NotNull;
import lombok.Getter;
import lombok.RequiredArgsConstructor;

@Getter
@RequiredArgsConstructor
public class SequenceRequest {
    @NotNull(message = "회차 정보는 필수입니다.")
    private final Integer sequence;

    @NotBlank(message = "공연일시 정보는 필수입니다.")
    @JsonFormat(pattern = "yyyy-MM-dd HH:mm")
    private final LocalDateTime startDateTime;

    public Sequence toEntity(Goods goods) {
       return Sequence
          .builder()
          .sequence(this.sequence)
          .startDateTime(startDateTime)
          .goods(goods)
          .build();
    }

}

 

Entity 생성자

@Builder
private Sequence(int sequence, LocalDateTime startDateTime, Goods goods) {
    this.sequence = sequence;
    this.startDateTime = startDateTime;
    this.goods = goods;
}

 

 또한 Entity에서 사용하던 방식에서 @ColumDefault를 추가하여 JPA에서의 초기 Default값을 설정하여 DB의 컬럼 정의에 대해서 설계의 명확성을 추가했다.

@ColumnDefault("0")