search

snack-news / Snack-BE

5 stars 3 forks source link

News와 Picks 통합 #178

Closed Delf-Lee closed 4 years ago

Delf-Lee commented 4 years ago

왜 해당 이슈가 개선되어야 할까요? 🧐

이렇게 하면 멋지게 해결할 수 있을거예요🍺

Reference

fyi @NESOY

Delf-Lee commented 4 years ago

요구사항

News와 Picks를 동시에 내려준다

해결 방법

위의 요구사항을 해결하기 위해 3가지 방법을 고안

CASE 1: Entity 변경 - 추상화

결과(예상)

CASE2: Entity 변경 - 포함

코드상에서 Picks라는 개념을 없앤다.

결과(예상)

CASE3: Service에서 처리

결과(예상)

Delf-Lee commented 4 years ago
NESOY commented 4 years ago

@Delf-Lee 저는 3번째 방법도 나쁘지 않다고 생각해요 :) 하나로 묶을려고 하는 것은 여러가지 책임을 하나로 묶는 것으로 보이지 않을까요? 필요하다면 다른 회사들은 어떻게 구현했는지 찾아보는것도 좋은 방법이라고 생각이 들어요 ㅎㅎ

Delf-Lee commented 4 years ago

@NESOY 처음에는 저도 하나로 묶으려는 시도였습니다만, 스펙 자체가 picks가 없어지다시피 됐습니다.

그리고 case3가 힘든 가장 큰 이유(처음 고민때 간과한)중 하나는 두 엔티티를 따로 관리했을 때, 테이블도 별개가 되기에 두 테이블에서

라는 절차를 구현하기가 까다로워집니다. 지금보다 복잡한 쿼리를 다뤄야할텐데 repository 레이어를 건드려야할 것 같은 느낌이 드네요. 이렇게 된다면 주객전도가 될것 같습니다.

혹시 이를 해결할 수 있는 방법이 있다면 공유해주시면 감사하겠습니다:smiley:

NESOY commented 4 years ago

@Delf-Lee

스펙 자체가 picks가 없어지다시피 됐습니다.

이 부분이 스펙이 그렇게 진행되면 통합해도 상관없을거 같네요 ㅎㅎ

꼭 Repository에서 안하고 Service Layer에서 해도 되지않을까요? 하나의 비즈니스 로직이라도 생각이 드네요. 나중에라도 News에 다양한 컨텐츠들이 노출될 요구사항이 나올텐데 이를 미리 생각해두고 설계해두는 방향도 나쁘지 않아 보입니다 ㅎㅎ

Delf-Lee commented 4 years ago

@NESOY

꼭 Repository에서 안하고 Service Layer에서 해도 되지않을까요?

어떤 부분을 말씀하시는건가요?

NESOY commented 4 years ago

@Delf-Lee

지금보다 복잡한 쿼리를 다뤄야할텐데 repository 레이어를 건드려야할 것 같은 느낌이 드네요.

이 부분때문에 언급했습니다. :)

Delf-Lee commented 4 years ago

@NESOY 만약 둘을 통합(혹은 picks를 삭제라고도 표현 가능)한다면 Repository를 수정할 필요는 없을 것 같습니다.

만약 그렇지 않는다면.... 🤔

  • 업로드예정일(publisAt) 기준으로
  • news와 picks를 합쳐 n개만 가져온다

Service layer에서 이 조건을 잘 풀어나갈 수 있을지 의문이군요...

NESOY commented 4 years ago

@Delf-Lee

Service layer에서 이 조건을 잘 풀어나갈 수 있을지 의문이군요...

이 부분에 대해 앞으로 꼭 풀어야 할 문제라고 생각이 들어요.나중에는 뉴스뿐만 아니라 그 모든 것들이 노출될 가능성이 있다고 생각해보면 좋을거 같아요. 광고 / 동영상 / 사진 / 채용정보 등등 -> 예를 들어 페이스북의 피드를 보면 이해하기 편할거예요.

그렇다면 우린 API를 제공하고 FE쪽에서 Mixing하는게 좋지 않을까라는 생각이 들기도 하지만.. 만약에 A/B 테스트를 위해 A는 특정 회사 노출비율을 높히고 싶고 B는 특정 회사 노출을 줄인다라는 비즈니스를 구현하려면 구현하고 유지보수하는데 백엔드가 가져가는게 더 수월하다고 생각이 들어요 :)

뿐만 아니라 Repository가 꼭 DB가 아닌 경우일수도 있구요. Rest Client인 경우, NoSQL인 경우 등등 이런 부분을 잘 Mixing해서 내려주는 상황이 오면 어떻게 풀어갈까? 고민해보는것도 좋다고 생각해요 ㅎㅎ

Service Layer에서 출발하지만 시스템이 엄청나게 진화하면 이 부분이 하나의 시스템이 될 수 있지 않을까요? 👍