Programming/Study22 구체 클래스 vs 추상 클래스 vs 인터페이스 - 고객 / 바버 추상화하기 이전 글에서 현재 사용 중인 회원 도메인을 고객과 바버의 두 개의 도메인으로 분리하기로 했다. 고객은 바버샵과 연관관계를 맺지 않아도 되지만, 리뷰에 답글을 달거나 바버샵과 관련한 기능들을 수행하기 위해서 바버는 바버샵과 연관을 맺어야하기 때문이다. 한 가지 고민해 볼 점은 고객과 바버를 완전히 다른 도메인으로 분리하느냐, 엔티티 레벨에서만 분리하고 하나의 도메인(회원)에서 사용하느냐이다. 물론 둘을 완벽하게 분리해서 사용하는 것은 충분히 가능하다. 애초에 회원가입을 시도할 때, 해당 사용자의 직군을 기준으로 서버 쪽에 요청을 다르게 날리면 된다. 이후에는 클라이언트에 회원의 정보를 쏴줄 때마다 해당 사용자의 역할을 담아 보내고, 그에 맞게 클라이언트에서 다시 요청을 보내면 된다. 이전 글에서는 클라이언.. 2024. 2. 27. 일대다 단방향 연관관계를 피하고 싶어서 바버샵 프로젝트의 핵심은 뭘까? 뭐긴 뭐야 당연히 바버샵이지. 바버샵 테이블을 설계하면서 가장 고민한 부분이 '근무 중인 바버에 대한 정보는 어떻게 담을까'였다. 원장에 대한 정보는 바버샵 -> 사용자의 일대일 연관관계를 맺어주면 간단하게 해결할 수 있다. 문제는 근무 중인 바버에 대한 정보다. 개념적으로는 바버샵 -> 사용자의 일대다 연관관계가 된다. 반대로 보면 사용자 -> 바버샵의 다대일 관계로 풀어낼 수도 있다. 최근 프로젝트를 진행하고 JPA와 관련한 공부를 하면서 일대다 단방향 관계를 만드는 것은 썩 바람직하지 못하다고 생각하게 되었다. 데이터베이스 관점에서는 키 관리의 어려움이 있으며, 코드 레벨에서는 더 중요한 도메인이 덜 중요한 도메인에 의존하게 된다. 예를 들어, 게시글과 댓글이라는 예.. 2024. 2. 21. DB Entity -> Domain Entity로의 전환은 어느 계층에서 담당하는 것이 옳을까 헥사고날 아키텍처를 괜히 적용했나 싶다. 고민해야 할 영역이 지나치게 많아진 느낌이다. 지금 내 수준에서 이런 문제들에 대한 최선의 답안을 찾아내는 것이 가능할까? 싶은데, 뭐 그렇다고 고민하는 시간이 의미없는 것은 아니니까 일단은 생각해볼만 하다고 여겨지는 영역에 대해서는 최선의 답을 찾아내고자 한다. 기존의 ORM 전략을 사용한 프로젝트에서는 데이터베이스 계층에서 사용되는 엔티티가 곧 도메인 엔티티의 역할을 함께 했다. 이번 프로젝트에서는 ORM을 사용하지 않고 데이터베이스 엔티티와 도메인 엔티티를 분리했다. 외부 데이터베이스와 내부 도메인 로직은 확실히 분리하고자 하였고, 임피던스 불일치 문제 같은 데이터베이스 레벨의 문제가 도메인 로직에 스며드는 것을 방지하고자했다. 그러나 결국 서버는 데이터베이.. 2024. 2. 14. 웹소켓은 왜 쓸까? 구글에 '스프링 채팅 기능'을 검색하면 웹소켓을 활용해 스프링 채팅 기능을 구현했다는 글이 수십페이지가 검색된다. 이 사람들은 왜 기본적인 통신 방법인 HTTP를 사용하지 않고 웹소켓이라는 기술을 선택해서 채팅 기능을 구현했을까. 웹소켓을 사용하는 것이 어떤 이점이 있을까. 이를 알아보면 웹소켓을 사용해서 채팅 기능을 구현하는 당위성이 생길 것이다. TCP VS UDP 웹소켓이고 HTTP고 알아보기 전에 TCP와 UDP를 먼저 알아보자. 그래도 기본적인 통신 프로토콜은 알고 진행하는게 낫지 않겠는가? TCP, UDP는 모두 데이터 송신을 위한 통신 프로토콜이다. 둘의 가장 큰 차이는 우리가 통신하고 있다는 걸 알고있냐, 모르냐의 차이라고 할 수 있다. 위의 표에서 확인할 수 있듯이, TCP는 연결형 서비.. 2024. 2. 7. JWT 이대로 괜찮은가? 인증 / 인가에 JWT를 사용하여 구현하는 경우가 상당히 많다. JWT를 사용하는 이유는 Stateful해서 서버에 부하가 걸릴 수 있는 세션과 달리 Stateless하며, 중요한 식별값(아이디, 비밀번호 등)이 그대로 넘어가는 쿠키에 비해 안전하다는 것이다. 그런데 순수하게 Stateless한 JWT를 사용하는 것이 과연 옳은가? 이 부분에 대해서 의구심이 든다. Stateless하다는 것은 달리 말하면 서버가 해당 토큰에 대해 모른다는 것이다. 즉, 토큰을 사용한 공격에는 취약한 점이 있다. 동시에, 로그아웃을 명확히 구현해내기 굉장히 어렵다. 가장 널리 알려진 경우가 다중 로그인일 것이다. 순수 JWT를 사용하면 한 계정으로 여러 번 로그인 하는 것을 막을 수 없다. 그렇다고 이미 로그인한 사용자의.. 2024. 1. 2. 이전 1 2 3 4 5 다음 반응형
