항상 좋은 영상 감사합니다! 도메인 영역은 순수하게 해당 도메인을 나타낼 수 있는 용어를 사용하고 presentation layer는 도메인을 어떻게 표현하느냐에 따라 항상 달라질 수 있음을 염두에 두어라 라고 생각해도 괜찮을까요?! 추가적으로 약7:30부터 "domain 영역과 entity영역을 나눠서 사용했을때 지금 당장은 1:1이지만 domain 영역이 어떻게 응집이 실제로 일어나고, 빠지는지에 대해 알 수 있다"라고 하셨는데 도메인 영역에 변화 혹은 응집이 생겼을때 어떤 도메인과 엔티티를 분리했을때 어떤 효과를 볼 수 있는지 예시를 들어주실 수 있을까요?!
반정규화되어 있다고 보시면 될 것 같습니다! 정확히 보면 책장은 자신이 보유한 책들의 순서를 알 필요는 없습니다! 촘촘히 정규화를 한다면 아래 같은 테이블 구조일 텐데요! 실제 현재 니즈가 없기 때문에 + 조회 및 구현 상 직관적이고 편하게 반정규화 되어있는 상태라고 보시면 됩니다! (추후 니즈가 생겨서 필요해지면 마이그레이션 하는 과정도 보여줄 수 있겠네요 :D) - 책장 - 책장의 단(슬롯, 몇 층인지의 개념) - 아이템 - 책장의 단 과 아이템의 매핑 정보
안녕하세요! 좋은 영상 감사합니다 ㅎㅎ 궁금한점이 있는데 저는 개발할 때, 도메인 계층에 제미니님처럼 도메인 모델이랑 도메인 서비스 클래스를 두고 퍼사드 계층을 둬서 여러 도메인 서비스를 가져와서 사용하면서 이 퍼사드 계층에서 response 까지 말아서 던지는 스타일인데, 이 퍼사드 계층을 저는 core 에 둬서 response 객체가 core 에 항상 위치했었거든요... 퍼사드를 안두자니 도메인 서비스에서 다른 도메인 서비스가 필요하거나 컨트롤러에 코드가 추가되는 경우가 생기는거같아요. 이런 경우에서 해당 영상처럼 core 에서 response 를 떼버리고싶은데 좋은 의견있으실까요??
퍼사드에서 api response 까지 핸들링하는 것은 레이어가 깔끔하게 정리된 상태 같지는 않습니다! (다만 팀내 협의라면 인정하고 갈 수 있다고 보구요) 퍼사드에서 그 행위에 맞는 도메인 결과 객체를 돌려주고 프리젠테이션 레이어에서 response를 만드는 구조가 좋다고 보입니다. 안그러면 api response 와 도메인 객체가 섞여있을 것 같습니다. api 응답이 변경되야할 때 도메인 객체가 변경되는 것은 좋은 구조는 아닐 것 같다는 생각입니다!
팀 내 협의라면 어쩔 수 없이 협의상 가능하므로 프레젠테이션 레이어에 엔티티가 '전파'돼도 될 것 같습니다. 다만 API Response 자체가 Entity 가 되는 것은 DB 구조가 변경 시 API Response 가 변경되는 문제가 있기 때문에 하면 안 될 것 같습니다!
항상 좋은 영상 감사합니다!
도메인 영역은 순수하게 해당 도메인을 나타낼 수 있는 용어를 사용하고
presentation layer는 도메인을 어떻게 표현하느냐에 따라 항상 달라질 수 있음을 염두에 두어라 라고 생각해도 괜찮을까요?!
추가적으로 약7:30부터 "domain 영역과 entity영역을 나눠서 사용했을때 지금 당장은 1:1이지만 domain 영역이 어떻게 응집이 실제로 일어나고, 빠지는지에 대해 알 수 있다"라고 하셨는데 도메인 영역에 변화 혹은 응집이 생겼을때 어떤 도메인과 엔티티를 분리했을때 어떤 효과를 볼 수 있는지 예시를 들어주실 수 있을까요?!
두 번째 질문은 th-cam.com/video/gRrOUT-VeZ4/w-d-xo.html 요 영상에서 어느정도 해결이 된것 같습니다!! 감사합니다 ㅎㅎ
첫 질문은 적어주신대로 이해하셔도 될 것 같습니다!
다른 영상까지 찾아봐서 셀프로 답을 찾아주시다니..! 봐주셔서 감사합니다😄
믿고 보는 방송
봐주셔서 감사합니다!
이 영상의 핵심 내용은 아니지만, 선반 대신 선반의 아이템들이 "자신의 순위(priority)"를 관리하도록 디자인하신 이유가 궁금합니다. 책장과 책 으로 치환해서 생각해보면 책장이 "자신이 보유한 책들의 순서"를 관리하도록 할 것 같아서요
반정규화되어 있다고 보시면 될 것 같습니다!
정확히 보면 책장은 자신이 보유한 책들의 순서를 알 필요는 없습니다!
촘촘히 정규화를 한다면 아래 같은 테이블 구조일 텐데요!
실제 현재 니즈가 없기 때문에 + 조회 및 구현 상 직관적이고 편하게 반정규화 되어있는 상태라고 보시면 됩니다!
(추후 니즈가 생겨서 필요해지면 마이그레이션 하는 과정도 보여줄 수 있겠네요 :D)
- 책장
- 책장의 단(슬롯, 몇 층인지의 개념)
- 아이템
- 책장의 단 과 아이템의 매핑 정보
@@geminikims 감사합니다 이해완
안녕하세요! 좋은 영상 감사합니다 ㅎㅎ 궁금한점이 있는데
저는 개발할 때, 도메인 계층에 제미니님처럼 도메인 모델이랑 도메인 서비스 클래스를 두고
퍼사드 계층을 둬서 여러 도메인 서비스를 가져와서 사용하면서 이 퍼사드 계층에서 response 까지 말아서 던지는 스타일인데, 이 퍼사드 계층을 저는 core 에 둬서 response 객체가 core 에 항상 위치했었거든요...
퍼사드를 안두자니 도메인 서비스에서 다른 도메인 서비스가 필요하거나 컨트롤러에 코드가 추가되는 경우가 생기는거같아요.
이런 경우에서 해당 영상처럼 core 에서 response 를 떼버리고싶은데 좋은 의견있으실까요??
퍼사드에서 api response 까지 핸들링하는 것은 레이어가 깔끔하게 정리된 상태 같지는 않습니다!
(다만 팀내 협의라면 인정하고 갈 수 있다고 보구요)
퍼사드에서 그 행위에 맞는 도메인 결과 객체를 돌려주고 프리젠테이션 레이어에서 response를 만드는 구조가 좋다고 보입니다.
안그러면 api response 와 도메인 객체가 섞여있을 것 같습니다. api 응답이 변경되야할 때 도메인 객체가 변경되는 것은 좋은 구조는 아닐 것 같다는 생각입니다!
답글 감사합니다! 정말 죄송한데 하나만 더 여쭙겠스빈다..! 🙏
그러면 제가 팀협의로 별도의 도메인 객체를 안만들고 JPA 엔티티를 도메인 객체로 사용중인 상황인데, 이런 경우에는 프레젠테이션 레이어로 엔티티를 응답해줘도 정상적인 흐름일까요?
@@geminikims
팀 내 협의라면 어쩔 수 없이 협의상 가능하므로 프레젠테이션 레이어에 엔티티가 '전파'돼도 될 것 같습니다.
다만 API Response 자체가 Entity 가 되는 것은 DB 구조가 변경 시 API Response 가 변경되는 문제가 있기 때문에 하면 안 될 것 같습니다!
@@geminikims
친절한 답변 감사합니다