강의 수준 질문드려요

언어나 스프링 같은 문제라기 보다는, 경험과 관련이 있습니다. 개발 경험을 좀 더 하고 나서 다시 들어보시면 와 닿는 내용이 더 늘어날 겁니다.

6분 26초에 말하는 객체의 안에 있는 프로시저란 객체의 메서드를 말하는건가요?

네, 비슷합니다. 조금 더 말하면 외부나 하위 클래스에서 접근할 수 있는 메소드에 가깝습니다.

객체의 기능보다 속성을 먼저 추출하는 것에 대해 의견을 여쭤보고 싶습니다.

데이터를 구조화한 것에 관련 데이터를 조작하는 기능을 추가하는 것도 외부에 제공하는 기능으로 정의하는 게 맞습니다.보통 DB에서부터 구현이 출발할 때 말씀하신 것처럼 데이터 구조를 먼저 생각하고 그 다음에 기능을 도출하게 되죠.중요한 점은 캡슐화를 최대한 지키면 됩니다.실제 개발을 하다보면 당연히 아래 두 관점을 왔다 갔다 하게 됩니다.* 외부 관점에서 사용할 기능* 구현 관점에서 데이터/구조일방적으로 한 방향으로 설계가 진행되기 보다는 두 관점을 오가면서 설계가 완성되어 간다고 보면 됩니다.

의존 대상 객체를 직접 생성했을 때 문제에 대해 질문드립니다.

안녕하세요. 아래 코드를 보죠.public class SomeService { private SmsSender sender = new SmsSender(); public void doSome() { ... // DB 연동 등 작업 sender.send(to, msg); } }이 코드에서 SomeService는 SmsSender를 new로 생성해서 사용하고 있습니다. 즉 SomeService가 SmsSender를 의존하고 있죠.SMS가 아니라 알림톡으로 메시지를 보내라고 요구사항이 변경되고 알림톡 발송 기능은 AlimtalkSender에 구현되어 있다고 가정하면, SmsSender 대신에 AlimtalkSender를 사용하도록 기존 코드를 변경해야 할 겁니다.public class SomeService { private AlimtalkSender sender = new AlimtalkSender(); // 즉 위 코드처럼 SmsSender를 new로 생성해서 사용(의존)하는 SomeService 코드가 AlimtalkSender를 생성하도록 바뀌는 거죠.

1:N 매핑과 해당 방식 차이가 뭔가요?

개념적으로 하나인 대상을 매핑하고 싶을 때 사용합니다. 예를 들어 객관식 문제는 질문과 보기로 구성되어 있는데 이때 질문과 보기를 두 테이블에 나눠서 저장할 수 있을 겁니다. 여기서 '객관식 문제'를 DB에 매핑할 때 보기를 콜렉션을 사용해서 매핑할 수 있습니다.

JoinColumn 질문

@OneToOne+@JoinColum 설정을 하기 위해서 user_email 칼럼에 대응하는 칼럼을 설정할 필요는 없습니다.

1:N 매핑과 해당 방식 차이가 뭔가요?

1:N은 엔티티와 엔티티 간 매핑입니다.엔티티 간 매핑이므로 서로 독립적인 라이프사이클을 갖습니다.예를 들어, A와 B가 1:N 관계일 때 A를 삭제한다고 해서 A와 연관된 모든 B가 삭제되지는 않죠.물론 엔티티 간 연관에 영속성 전파 설정을 하면 같이 삭제되지만요. 반면에 값 콜렉션은 엔티티와 값의 관계입니다.즉 엔티티를 삭제하면 엔티티에 속한 값도 함께 삭제됩니다.또한 값만 따로 조회할 수 없습니다. 엔티티를 조회해야 엔티티에 속한 값도 같이 조회가 되지요.

7강에서 SecondaryTable을 왜 사용하지 모르겠습니다.

@Embedded로 매핑할 대상이 엔티티와 같은 테이블이 아닌 다른 테이블인 경우에, 조인할 테이블을 알려주기 위해서 @SecondaryTable을 이용하는데요,이해가 안 된다고 하는 부분이 @SecondaryTable 자체를 말씀하시는 걸까요? 아니면 @Embeddable을 다른 테이블로 매핑할 일이 있느냐를 말씀하시는 걸까요?

JPA 실무 @Entity을 @Embeddable 대체하는 경우가 많은가요?

@Embeddable은 값(Value)를 표현하는 모델을 매핑할 때 주로 사용합니다. 실무에서 @Embeddable을 잘 활용할수록 모델이 풍부해지죠. 이 값 모델을 잘 활용한다는 것은 그 만큼 조직/개인의 모델 방식/역량하고도 연결이 됩니다.그래서 조직/개인이 모델을 설계 결과물에 따라 사용하는 비율이 달라집니다. 동일한 테이블을 밸류로도, 엔티티로도 매핑한다는 것은 누군가에게는 엔티티인데, 누군가에는 밸류라는 얘기로 들립니다.명령 모델과 조회 모델을 나눠서 구현하면 그럴 가능성이 있다고 생각합니다(CQRS).명령 모델에서는 엔티티엔데, 조회 모델에서는 밸류라던가 하는 식으로요.

도메인과 JPA 엔티티

우선 개인적으로는 너무 완벽하게 JPA에 대한 의존을 제거하려고 노력하지 않아도 된다고 생각합니다. 큰 틀에서 구조를 깨뜨리지 않는 선에서 JPA에 의존하는 정도는 허용해도 괜찮다고 봅니다.Order와 OrderJpaEntity를 꼭 분리해야 한다면 Order를 인터페이스나 추상 클래스로 만들고 OrderJpaEntity는 Order를 상속받는 구조를 가져가는 방법이 있습니다. 이때리포지토리는 save나 find에서 Order 타입을 사용하고리포지토리 인터페이스를 구현한 클래스는 내부적으로 OrderJpaEntity를 사용합니다. 유사한 방식으로 Order 인터페이스/추상 클래스가 있고, 이 Order를 상속받은 클래스가 내부에 필드로 JPA용 엔티티를 필드로 가져서 변경이 발생하면 전파하는 방법을 사용할 수도 있을 듯 합니다.하지만 이렇게 해서 얻게 되는 실질적인 이점이 무엇이 있는지는 한 번 고민해 볼 필요가 있습니다.