JPA model strategy: ERD, JPA, and OOP

[hughesgoon]

데이터베이스 관점에서의 ERD와 객체지향적 관점, 그리고 JPA 특유의 이슈가 조합되어 유저와 연관된 몇가지 논의가 진행중인데요. 여기 기록으로 남기고자 이슈 개설합니다.

1. 프로필과 유저 관계
   • 프로필은 유저에 1:1 종속관계인 VO이지 않는가.

   • 4 코드짜다보니 엔티티가 돼야하는 것 같기도 하지 않나요?

   • (영속성) 프로필과 유저는 각각 독립적인 Entity로 하고, 유저가 주인인 OnetoOne으로 필요할때만 fetch join 해보는 건 어떨까요?
   • (도메인) 유저 도메인 객체가 프로필 클래스를 포함하도록 비즈니스 로직 객체를 따로 두면 어떨까요?
2. oAuth 객체의 개념
   • oAuth 객체는 할 수있는 행위가 없는데, 엔티티가 되어도 될지, VO 혹은 임베디드 컬렉션으로 둬야할지?
   • @jeeheaG 임베디드 컬렉션이면 테이블 분리가 안되지 않는지? / Entity vs VO라면 VO에 가까울 듯
3. 패널티 객체의 개념
   • 패널티는 독립 엔티티인 것으로 합의봐도 될까요?
   • 그렇다면 유저에서 이거가능?(유저, 행동) 메소드를 하는게 맞나요?
   • 아니면 패널티가 이거가능?(패널티, 행동) 메소드를 하는게 맞나요?

[ekgns33]

• 첫번째 안건에 대해서는 일대일로 분리해서 개발해보고 여러 기능이 추가되면서 이게 엔티티로 승격할 정도의 데이터가 아니다라고 판단되면 유저테이블에서 VO로 들고있게 하는게 어때요
• 임베디드 컬렉션이어도 테이블 분리를 할 수 있긴합니다. 그런데 나중에 소셜 연동으로 소셜 정보가 하나의 아이디를 가리키게 하려면 엔티티로 두어야하지 않을까 싶습니다. OAuth객체에서 User객체의 상태에 대한 수정같은게 없다면 테이블은 가르고 OAuth에서 유저의 PK를 간접참조하도록 설계하는 것은 어떨까요?
• penalty와 유저는 다른 도메인으로 봐야할 것 같아요. 따라서 이경우에는 페널티는 말그대로 어떤 id에 어떤 페널티가 부여된 것만을 의미하고 시스템이 그 penalty를 보고 유저의 상태를 바꾸게하는게 어떨까요? 유저테이블에 isBlocked같은 필드로 쿼리, 서비스 이용시에 필터링을 두면 복잡한 과정이 줄어들 것 같기도해여

[jeeheaG]

• 프로필과 유저 관계 PR 에서도 한참 고민한 것 같아서 이제는 선택의 문제같네유 다훈님 말씀대로 쓰면서 적잘하게 바꿔가는것도 좋다고 생각합니다~

• oAuth 객체의 개념 VO에 가깝다고 생각했는데 나중에 소셜 연동 합치는 상황이 있군여.. 흠 이건 뭐가 좋을지 잘 모르겠네요 @hughesgoon 님 생각은 어떠신가여

• 패널티 객체의 개념 오 패널티 객체를 그렇게 보고 계셨군요? 로직 짤 때 이상하게 느껴질 것 같아서 걱정이었는데 그런 식으로 활용하면 또 괜찮을 것 같습니다

[hughesgoon]

• 프로필과 유저 관계
  • 일단 분리해서 해보고, 나중에 VO로 바꿀지 고민해보는 것 좋습니당.
• oAuth 객체의 개념
  • 테이블 가르고, 엔티티도 가르고, oAuth가 User FK가지도록 하는게 좋을 것 같습니다.
• 패널티 객체의 개념
  • 유저와 다른 도메인으로 두는 것 동의합니다.
  • 다만 is_blocked 의 경우, 단순히 계정 블락의 개념이라면 칼럼으로 둬도 되는데,
  • 일시정지, 댓글금지 그런 확장이 예정되어 있다면, 지금 ERD대로 별개 엔티티로 독립적으로 두고
  • 유저가 어떤 행위를 할 수 있는지?를 유저 객체에서 확인하게 해보는게 좋지 않을까유