분류 전체보기196 중간 테이블은 어느 도메인에 위치시켜야할까? 데이터베이스 설계를 하다보면 종종 다대다 관계를 마주한다. 그리고 다대다 관계를 해결하기 위해 중간 테이블을 사용하는 것이 일반적이다. 다대다 테이블을 사용하면, @ManyToMany와 @JoinTable을 사용하는 것보다 유연하게 테이블 및 소프트웨어 디자인이 가능하다. 중간 테이블에 더 많은 정보를 담을 수 있다. @JoinTable에는 양쪽 테이블의 id값밖에 담지 못한다. 추가 칼럼을 담을 수 있다는 것은 곧 해당 테이블이 새로운 개념으로 확장될 수 있다는 의미다. 그런데, 그럼 중간 테이블은 어디에 두는 것이 옳을까? 예를 들어, A라는 도메인과 B라는 도메인의 중간 테이블인 C엔티티는 어느 도메인 패키지에 두는 것이 옳을까. 내가 생각한 방안은 크게 두 가지였다. A 또는 B 도메인의 하위 .. 2024. 3. 26. HTTPS는 왜 쓸까? : HTTPS 동작 과정 알아보기 아직 면접에서 질문 받은적은 없는데, 혹시 질문이 나올 수도 있을까봐 간만에 다시 공부하는 분야다. HTTPS는 왜 쓸까? HTTP랑은 뭐가 다를까? 사실 다른 점은 딱 하나다. 주고받는 데이터에 암호화를 하느냐 마느냐. 차이점이 딱 하나니까, 사용하는 이유도 당연히 저 하나의 차이에서 나온다. HTTPS는 HTTP보다 데이터를 안전하게 주고 받을 수 있다. 그렇다고 면접에서 이렇게만 대답할 순 없잖아. 오늘은 HTTPS가 안전하게 데이터를 주고받을 수 있게 해주는 암호화 / 복호화 방식을 알아보고자 한다. HTTP HTTP와 HTTPS의 차이는 주고받는 데이터에 암호화를 하냐 마냐의 하나밖에 없다고 했다. 이 말은 다시 말하면, HTTP던 HTTPS던 데이터를 주고받는데 사용된다는 것이다. 여기서 굳이.. 2024. 3. 4. 바버 - 바버샵 최종장 : 중간 테이블... 써야겠지? 회원과 바버샵 간의 연관관계를 다루는 (아마) 최종 게시글이다. 결국 중간에 테이블을 하나 사용하기로 했다. 그렇다고 조인해서 정보를 사용하는 경우는 아마 없을 것 같긴하다. 일대다의 방향성을 지닌 연관관계를 사용하지 않고자 최대한 노력하고있고, 그럼 굳이 테이블을 조인해서 어떤 정보를 찾아올 이유도 없다. 게시글을 조회하면 댓글 리스트에 대한 조회 요청이 같이 오는 것과 마찬가지로, 바버샵을 조회하면 해당 조인 테이블에 대한 조회 요청도 같이 보낸다. 이렇게 엔티티 간 연관을 끊고 id에 의한 약한 연관관계를 유지하면서, 좀 더 상위 도메인을 방어적으로 다룰 수 있다. 아무튼 처음의 생각으로 돌아가보자. 처음 생각했던 테이블 설계는 아래 그림과 같았다. Member도메인 자체를 두 개의 도메인으로 분리.. 2024. 3. 3. 롤백 - 회원을 왜 나눠 아주 바보같은 생각이었다. 회원이 바버샵과 연관이 있다고 회원을 나눈다니. 이번 프로젝트 설계의 가장 근간은 회원은 절대 지킨다였다. 그런데, 회원이 바버샵과 연관이 있다고 회원 도메인에 바버샵 도메인을 침투시킨다? 무슨 이런 바보같은... 회원과 바버샵이 연관되어 있으면, 회원이 바버샵에 의존하는게 아니라 바버샵이 회원에 의존하는게 맞다. 이런 기본 원칙을 까먹고 멍청하게 프로젝트를 진행하고 있었다.... 이전에 생각했던 바버와 바버샵 클래스를 코드로 표현하면 아래와 같다. class Barber { ... private final BarberShop workPlace; ... } ////////////////////////////// class BarberShop { ... private final .. 2024. 2. 28. 구체 클래스 vs 추상 클래스 vs 인터페이스 - 고객 / 바버 추상화하기 이전 글에서 현재 사용 중인 회원 도메인을 고객과 바버의 두 개의 도메인으로 분리하기로 했다. 고객은 바버샵과 연관관계를 맺지 않아도 되지만, 리뷰에 답글을 달거나 바버샵과 관련한 기능들을 수행하기 위해서 바버는 바버샵과 연관을 맺어야하기 때문이다. 한 가지 고민해 볼 점은 고객과 바버를 완전히 다른 도메인으로 분리하느냐, 엔티티 레벨에서만 분리하고 하나의 도메인(회원)에서 사용하느냐이다. 물론 둘을 완벽하게 분리해서 사용하는 것은 충분히 가능하다. 애초에 회원가입을 시도할 때, 해당 사용자의 직군을 기준으로 서버 쪽에 요청을 다르게 날리면 된다. 이후에는 클라이언트에 회원의 정보를 쏴줄 때마다 해당 사용자의 역할을 담아 보내고, 그에 맞게 클라이언트에서 다시 요청을 보내면 된다. 이전 글에서는 클라이언.. 2024. 2. 27. 이전 1 2 3 4 5 ··· 40 다음 반응형
