Reader, Writer 쓰지말자 (feat. implement layer)

Рет қаралды 3,658

제미니의 개발실무

Күн бұрын

Пікірлер: 29

@user-tw3be5ip9h 17 күн бұрын

핵심은 천천히, 기존 시스템을 존중하고 융화돼서 같이 바꿔나가자는 거군요. 너무좋네요

@geminikims 14 күн бұрын

맞습니다! 잘 이해해주시고 공감해주셔서 감사합니다!😁

@socresf-x2m Ай бұрын

좋은 영상감사합니당 :) 설득의 근거가 아니라 핑계거리를 찾는 사람이 많은 것 같아요

@geminikims Ай бұрын

맞습니다😢 많이 안타까운 부분이죠..! 항상 댓글 주시고 봐주셔서 감사합니다!

@hyeonsu-hl2ff Ай бұрын

오늘도 쓰지말자 시리즈 잘봤습니다 ㅎㅎ 저도 물론 제미니님의 글을 보고 인사이트를 얻었지만, 기본적으로 '지속적, 성장가능한' 이라는 목표가 있고 그럴 가능성이 있는 프로젝트를 진행할 때 추가적인 레이어를 도입해야 한다고 생각했습니다. 그리고 레이어를 도입해서 인프라 - 비즈니스 간에 의존성을 낮추어 비즈니스 로직이 변경되야 하는 이유(ex. 기본적인 요구사항의 변경)가 적어도 외부에 의해서 변경되면 안되겠다고 생각해서 implement 레이어를 도입했습니다. 좋은 영상 감사합니다 ~

@geminikims Ай бұрын

충분히 이해하시고 고민하시고 사용하시는 것 같아서 너무 좋네요!👍 봐주셔서 감사합니다!

@LeeMember-z5p Ай бұрын

작은 회사에서 레이어 컨벤션을 만들어가는데 항상 큰 인사이트를 얻습니다. 배워가는 걸 "고민하면서" 쓸 수 있도록 노력해야겠네요.

@geminikims Ай бұрын

도움이 되셨다면 다행입니다! 말씀 해주신대로 항상 고민하면서 쓰는게 가장 중요한 핵심인 것 같습니다!!

@우칸많사 Ай бұрын

예전부터 쭉 보면서 정말 많은 인사이트를 얻어갑니다. 아직 주니어라 많은 부분을 이해하기엔 힘들지만, 저도 영향을 받아 지속 성장 가능성에 대해서 중요하게 생각하게 됐는데 그 앞에 함께를 붙이니 많은 것들이 어렵게 느껴졌습니다. 그래서 요즘은 함께 지속 성장 가능한 소프트웨어를 만드는 법, 혹은 함께 지속 성장 가능한 소프트웨어를 만드는 팀이 되는 법에 대해 많이 생각하게 됩니다 :).. 남은 한 해도 잘 마무리 하시고 항상 건강하시길 바랍니다

@geminikims Ай бұрын

소프트웨어는 절대 혼자서 만들 수 없기에 적어주신 것 처럼 함께를 계속 고민해야합니다😃 이해가 안가시는 부분이 있는 것을 떠나서 계속 고민하신다는 것이 아주아주 중요한 부분이고 바람직한 모습 같습니다👍 저는 정답을 말하는 사람이 아니니 쭉 고민하시면서 본인만의 지속 성장을 구축해보시길 추천드립니다!! 봐주셔서 감사하고 내년도도 화이팅 하시길 바라겠습니다😀

@주호빵-y5x Ай бұрын

핵심은 무지성으로 만들지말고 프로젝트 상황에 맞춰 사용하자네요. 그리고 다른 영상에서도 공통적으로 전달하시려는 메시지가 "소프트웨어" 이기 때문에 그 환경, 프로젝트에 맞게 설계하고 구현하자가 맞는거 같네요. (정답은 없다!) 오늘도 좋은 인사이트 얻고 갑니다.

@geminikims Ай бұрын

맞습니다!! 무지성 절대 금지!!🫡 소프트웨어는 정말 상황이 모두 다르고 정답지가 없는 영역이기 때문에 적어주신 댓글에 100% 공감합니다! 알차게 정리된 댓글 감사드리고 봐주셔서 감사합니다!

@HoduMango Ай бұрын

저도 구현 레이어인줄 알았는데 아니었군요..부끄럽네요 여러모로 반성하게 되는 영상이네오 감사합니다!

@geminikims Ай бұрын

부끄러우실 필요는 없습니다!! (그리고 저도 혼동을 드리는데 일조를 했다보니ㅎㅎ.. 연대책임이죠..!) 봐주셔서 감사합니다!😀

@Son-lm5mf Ай бұрын

오늘도 잘 보고 갑니다 : >

@geminikims Ай бұрын

봐주셔서 감사합니다!

@래박 Ай бұрын

OOP 에서 말하는 도메인모델들을 구현 레이어에 놓는다 라고 이해했습니다 OOP 의 중요성을 오늘도 느끼고 있습니다

@geminikims Ай бұрын

맥락상 상당히 유사하다고 볼 수 있느나, 사실 제가 설명하는 방향성 기준으론 OOP를 떠나서 비즈니스를 복잡하지 않게 하기 위한 “도구(요소,속성,재료 등 뭐로든 표현가능)를” 를 구축 할 수 있다는 것이 핵심이긴 합니다! 다만 이 것 자체를 잘 따져보면 설명하신 것과 유사하긴합니다 😀 봐주셔서 감사합니다!

@sj441888 Ай бұрын

repository pattern과 그보다 벗어나는 넓은 범위의 읽기 dao에 대한 로직을 분리해서 사용했을때에 대한 이야기가 맞을까요? 뭔가 도구레이어, reader,writer라는게 본적없는 말이다 보니까 덜 와닿는 부분이 있네요 그리고 implementation layer는 구현계층이 맞지 도구레이어라고 하면 오히려 혼란줄거 같네요

@geminikims Ай бұрын

repository 나 dao 관련 된 얘기는 아닙니다 kzbin.info/www/bejne/pprQinycjaiIm5o 궁금하시다면 위의 영상이 도움이 될 수도 있을 것 같아요 (아닐 수도 있구요) 도구레이어는 제가 임의로 지정해서 쓴거라 못 들어보신게 당연한 것 같고, reader writer도 용어 자체가 중요한 건 아닙니다 팀/회사 마다 저런 레이어나 계층이나 구성 도구들에 대한 규칙을 유연하게 가져가며 생각을 많이 해야한다는게 핵심이죠 그리고 implementation layer 라고 한적은 없습니다 implement(명사:도구) layer 로 지칭했고 굳이 저 헷갈리는 단어를 쓴 사유는 compoent layer 라고하니 사람들이 spring @Component 를 생각하더라구요 근데 여러모로 혼동이 있는 것 같아서 단어는 바꿀까합니다. 결과적으로 이것 또한 용어나 단어 자체가 중요한 건 아니고 그것이 필요한 배경과 내용이 중요한거니까요. (다만 이해에 대한 혼동을 줄이기위해 한글을 쓰는게 나을 수도 있겠다 싶긴하네요)

@Za__an 18 күн бұрын

안녕하세요 항상 영상 잘 보고 있습니다! 영상 참고하여 프로젝트를 진행하고 있는데요. 모놀로식 구조에서 Look Aside 방식으로 캐시를 사용하고자 하는데요. 이 때 Service Layer에서 Reader를 호출하여 캐시가 있다면 응답하고 없다면 다시 Reader를 호출하여 DB 조회를 한 뒤, Processor를 호출해서 캐시를 저장하는 구조와 CacheReader, CacheProcessor를 추가로 생성하여 Service Layer에서는 최대한 비즈니스 로직만을 담는 방식 중 어떤 것이 좋은 방법인지 궁금합니다. 제 생각에는 전자는 Implement Layer를 도입한 의미가 희석되는 대신 프로젝트의 복잡성이 줄어들테고, 후자는 명확한 책임 분리와 유지보수성 등이 좋아진다는 장점이 있을 것 같습니다. 제미니님께서는 어떤 방법이 낫다고 생각하시는지 궁금합니다. 감사합니다 :D

@geminikims 14 күн бұрын

우선 이 부분도 주요 개념들의 형태나 시스템의 규모나 특이점에 따라 유연하게 선택 할 수 있는 것 같습니다 다만 저 같은 경우는 대부분 일반적인 케이스에서는 Cached* 클리스를 사용하여 풀어내는 것을 더 선호하는 편 입니다 (사실 이 부분도 비즈니스 영역에서 cache 라는 기술적인 부분을 알게 할지 말지가 중요한 선택지 이긴합니다, 데이터 접근 영역이 더 커져야 할 수도 있는 신호가 있을 수 있구요) 왜 더 전략을 선호하냐면 기본적으로 비즈니스 레이어에서 데이터에 존재 유무에 따른 분기 로직을 같고 있는 것은 조금 더 기술 및 구현에 가까운 로직일 가능성이 높다고 보기 때문입니다 (다만 개발하는 서비스의 본질이 데이터 조회라면 또 다른 얘기겠지요ㅎㅎ) 모쪼록 저는 말씀해주신 것 중 후자를 선호합니다만, 특정 하나가 정답인 부분은 없다고 보여서 팀내 협의와 프로젝트 통일성 측면 고민을 해보시면 좋을 것 같습니다!

@조원진-y2g 18 күн бұрын

안녕하세요 제미니님. 항상 영상 잘 보고 있습니다. 제미니님 프로젝트 구조에 영감을 받아서 실제 프로젝트에 적용해서 잘 사용하고 있는 중입니다. 혹시 배치 모듈도 core-api 모듈처럼 core-domain을 이용해서 ItemReader, ItemWriter를 구현하시나요? 이전 배치 모듈은 CursorItemReader나 PagingItemReader를 구현하기 위해 jpa, querydsl을 직접 의존을 했었는데 순수 도메인객체 구조로 변경 후에는 그 방법이 고민되어서 질문 드립니다!

@geminikims 14 күн бұрын

제가 정확히 이해했는지 모르겠디만 domain 모듈이 나온상태에서 배치 모듈 구성이라면 core-batch 모듈을 구성하고 기본적으론 core-domain 을 사용하게 합니다! 다만 적어주신 것과 같이 배치에서는 조회 특성이 다를 수 있기 때문에 이것을 domain에 넣을지는 선택이 필요한 것 같습니다 제 경우는 대부분의 경우 배치에서 조회하는 패턴은 도메인 고유의 성격이 아닌 배치 특수의 형태라고 가정하고 core-batch 모듈 쪽에 명시적으로 구현체를 두거나, 가능하다면 core-domain 를 wrapping 해서 데이터 조회를 하는 방식을 접근하긴 합니다! 다만 이는 구조나 만드는 배치 성향이나 데이터 특성, 도메인 특성에 따라 너무 다양한 전략이 있을 것 같습니다! 질문 감사드립니다!

@조원진-y2g 14 күн бұрын

@@geminikims 아하 그럼 ItemReader나 ItemWriter가 읽어들이는 대상인 @Entity나 @Document도 배치 모듈에 두지 않고(또는 db 모듈을 의존하지 않고) core-domain을 거쳐서 사용하게 되겠군요.

@geminikims 14 күн бұрын

넵 다만 페이징 조회나 벌크 처리 등등 특수 처리 전략이 필요하다면 배치 모듈에서 직접적으로 핸들링하는 방식을 선호합니다! 기본적인 조회나 domain 모듈 활용이 될 수 있다면 좋지만 배치가 고도화 되면 필수적으로 분리 구현이 필요할 가능성이 높긴합니다! 그래서 선택이 필요한건 특수한 조회 형태도 도메인으로 취급하고 관리할 것인지 그게 타당한지를 잘 검토하는게 필요할 듯 합니다 (케이스 별로 다르다고 생각합니다😀)

@조원진-y2g 14 күн бұрын

@@geminikims 덕분에 궁금증이 해결 됐습니다. 정말 감사합니다.