안녕하세요!! 따끈한 신입입니다! 영상 너무 잘보고있습니다!! 먼저 부족한 질문이라 사과의 말씀 먼저 드립니다 ㅠ 취준시절 구현에만 집중하다보니 A도메인의 기능은 A서비스 클래스에 모두 넣었는데, 요즘 듣는 얘기가 구현은 잘하지만 객체의 책임, 역할과 로직의 흐름이 무분별해 신경써야될거 같다는 피드백을 듣습니다.. 최대한 신경쓰려고 하지만 추상적인 피드백에 어떤 기준으로, 어떻게 나눌지 고민이 됩니다.. 혹시 재미니님은 어떤 기준으로 어떻게 나누는지, 추천하는 서적이 있는지 궁금합니다!
재미니님의 유튜브 구독을 해놓고? 나긋나긋한 목소리를 들으며 왔다리 갔다리할때 들었었는데 토스 관련 영상을 보니 그게 재미니님이시더라고요?! Slash에서 발표해주신 세션 보고도 몰랐는데 오늘 비슷한 주제로 영상을 올려주셔서 알아봤네요. 바쁘실텐데 영상 올려주셔서 감사합니다 잘 봤어요 🥹
질문이 있어요! 현재 모듈은 api - domain - infra 크게 이렇게 3개로 나누어져있고 패키지는 도메인 단위로 나누어서 작업중입니다. 제미니님의 말씀대로 이전 프로젝트에서 domain 모듈내에서 또 도메인 단위로 모듈을 나누니까 의존성 지옥이 펼쳐지더라고요... 그래서 이번에는 패키지로만 구분을 해서 작업중입니다. 하지만 그래도 domain 패키지 간의 순환참조는 피하기위해 DIP나 이벤트를 활용해서 의존성 방향을 한쪽으로만 생기도록 하고있습니다. 근데 이런 작업이 머리가 아프기도하고 이게 지금 도메인 단위 모듈로 분리했을떄랑 무슨 차이인지 모르겠기도하고... 제미니님은 도메인 패키지 간의 순환참조에 대해서는 어떻게 해결하시나요?
코드를 보지 못해서 케이스를 제가 정확히 이해하진 못했으나 기본적으로 어떤 구조에서건 `순환 참조`는 피해야하는 것 같습니다! (적어주신대로 모듈 구조, 패키지 구조 차이 없는 부분 같아요) 해결하는 전략은 케이스 마다 다를 것 같습니다 (예제가 없으니 설명이 다소 어렵네요) 대부분 케이스에선 적어주신 것 처럼 `개념(도메인)` 들에 대해서 의존성을 한 방향으로 하도록 구현을 다지면 순환 참조는 자주 발생하는 것 같지 않습니다, 혹시 문제가 있으신 사례를 각색하여서 알려주시면 더 디테일하게 답변 드려보겠습니다!
@@geminikims 아 그럼 제가 고민했던 부분을 말씀드려볼게요! 결제 - 주문 - 배송 - 배송 부가서비스 이렇게 4가지 개념이 있습니다 저는 주문의 비즈니스 레이어에서 주문을 할 경우 배송 예약 및 배송 부가서비스까지 예약하는 로직을 주문 비즈니스에 나타내고 싶었습니다! 따라서 처음에는 "배송"과 "배송 부가서비스"의 컴포넌트를 가져와서 비즈니스 레이어에 두니 "배송"과 "배송 부가서비스"도 "주문" 개념을 의존하고 "주문" 개념도 이 2가지 개념을 의존하는 순환참조가 발생하게되었습니다. 물론 코드 실행에는 문제가없었지만 마음속에서 찝찝한 마음이 들어 "주문" 개념에 인터페이스를 만들어 의존성 역전을 통해 의존성이 한쪽으로만 흐르도록 만들긴했습니다. 여기서 제가 궁금했던 점은 자연스러운 의존성 방향은 "배송 부가서비스" -> "배송" -> "주문" 이렇게 흐르는게 정상이지만 주문 비즈니스 로직에 "배송 부가서비스"를 예약하는것도 보여주고싶은 저의 욕심으로 "배송 부가서비스"에서 "주문" 개념도 바로 의존하게 되었습니다. 근데 이럴 경우에 인프콘에서 제미니님이 말씀하신 "격벽"을 2개를 뛰어넘어서 "주문"에 바로 의존하게 되는데 이렇게 해도 되는건지 궁금합니다! 참고로 "배송 부가서비스"는 원래는 "배송"개념과 함께였으나 크기가 커질거같아 배송에서 개념을 분리해서 생성되었습니다! 혹시나 참고가 되실까하여 gist 코드 스니펫 링크 남겨볼게요! gist.github.com/JiwonKKang/5a05ca752fba37b54836d62c624c9de2 설명이 제대로 됐는지 모르겠네요... 미리 부족한 설명 읽어주셔서 감사합니다
@@강지원-j8c 와우 상세한 질문 감사드립니다 우선 영상으로 얘기해보기전에 간단하게만 답변 드려보면 (제 말이 절대 정답은 아닙니다!! 코드 단편만 본 얘기다보니 참고만 해주세요!) 개념의 정석 흐름상으론 "주문 -> 배송 -> 배송 부가서비스" 가 되는 흐름에서 현재 수준이 완전히 "문제" 라고 보기엔 어렵다고 보입니다! 다만 적어주신 것 처럼 "주문" 과 "배송" 사이엔 격벽이 있으면 상당히 관리에 유용할 것 같은데요! 한가지 관점으로 보면 "FullDining" 이 "배송 부가서비스" 인데 "FullDining" 를 "주문 도메인"으로 생각 하시는 것 같아서 이 부분을 다시 생각 해보실 수 있을 것 같습니다! 저도 잘 모르고 적은 것이지만 "FullDining" 이 "배송 부가서비스" 라면 "FullDiningInfo" 은 "배송 개념" 의 하위 이지 않을까요? 그렇다면 격벽을 역으로 넘어서 참조하고 있지는 않은 것 같습니다! 모쪼록 현재 부분 코드로만 봤을때에는 어떤 관점으로 보냐에 따라 다른 부분이기도하고, 현재 수준정도 참조에서는 심각한 문제가 없어보이니 추후 더 큰 오염이 감지 될 때 개선으로 봐도 충분한 부분 같습니다! ---------- 좀 더 자세히 살펴보는 얘기는 github.com/geminiKim/dev-practice/issues/82 해당 이슈를 통해 추후 영상으로 얘기해보도록 하겠습니다 상세한 질문 감사드립니다!
오 이번주에 팀 아키텍처 문서 만들려고 했는데 제맘 꽤뚫어 보셨나요.. 몇가지 질문이 있습니다! 1. 레이어 규칙을 정하기전에 개발되었던 모든 프로젝트들도 시간이 날때마다 틈틈히 적용하시나요? 아니면 규칙을 정한 이후 프로젝트에만 적용하시나요? 2. Implement 계층에서 디자인 패턴을 적용할시 implement 계층 안에 strategy 혹은 template 등 디자 인패턴 네이밍 그대로 패키지를 두시나요? 감사합니다!!
1. 프로젝트마다 성질이 다르기 때문에 전체적용을 무조건 하지는 않습니다! 이후 생기는 프로젝트도 기본 룰에서 변화해야할 부분을 점검하면서 조율해나가는 편입니다! 그래서 전체 프로젝트에 일괄 적용하는 식 보다는, 해당 프로젝트 작업을 해야할때 마다 개선 규칙을 적용할게 있나 고민해보는 것 같아요! 2. 요것도 케바케이긴한데 가급적 사용한 패턴을 패키지명으로는 잘 안 쓰려고합니다! 패키지는 개념 기준으로 묶는 편이에요! 다만 관리가 까다롭거나 패턴으로 묶고 구현체를 고립시키는게 더 낫다면 그런 패키징도 가능하다고 생각합니다! 오늘도 봐주셔서 감사합니다! :D
![Blox Fruits Dragon Rework Update [Full Stream]](http://i.ytimg.com/vi/EqDAp8udhm0/mqdefault.jpg)
안녕하세요!! 따끈한 신입입니다! 영상 너무 잘보고있습니다!! 먼저 부족한 질문이라 사과의 말씀 먼저 드립니다 ㅠ
취준시절 구현에만 집중하다보니 A도메인의 기능은 A서비스 클래스에 모두 넣었는데, 요즘 듣는 얘기가 구현은 잘하지만 객체의 책임, 역할과 로직의 흐름이 무분별해 신경써야될거 같다는 피드백을 듣습니다.. 최대한 신경쓰려고 하지만 추상적인 피드백에 어떤 기준으로, 어떻게 나눌지 고민이 됩니다.. 혹시 재미니님은 어떤 기준으로 어떻게 나누는지, 추천하는 서적이 있는지 궁금합니다!
추후 영상으로 다뤄보겠습니다!
이슈: github.com/geminiKim/dev-practice/issues/93
와 재미니님 좋은 영상 감사합니다. !
봐주셔서 감사합니다!
재미니님의 유튜브 구독을 해놓고? 나긋나긋한 목소리를 들으며 왔다리 갔다리할때 들었었는데 토스 관련 영상을 보니 그게 재미니님이시더라고요?! Slash에서 발표해주신 세션 보고도 몰랐는데 오늘 비슷한 주제로 영상을 올려주셔서 알아봤네요. 바쁘실텐데 영상 올려주셔서 감사합니다 잘 봤어요 🥹
아이고ㅎㅎ 슬래시 발표도 봐주셨다니 감사하네요ㅎㅎ.. 봐주셔서 감사합니다!
9:14 제미니님의 인간적인 모습
🤣🤣🤣
질문이 있어요!
현재 모듈은 api - domain - infra 크게 이렇게 3개로 나누어져있고
패키지는 도메인 단위로 나누어서 작업중입니다.
제미니님의 말씀대로 이전 프로젝트에서 domain 모듈내에서 또 도메인 단위로 모듈을 나누니까 의존성 지옥이 펼쳐지더라고요...
그래서 이번에는 패키지로만 구분을 해서 작업중입니다.
하지만 그래도 domain 패키지 간의 순환참조는 피하기위해 DIP나 이벤트를 활용해서 의존성 방향을 한쪽으로만 생기도록 하고있습니다.
근데 이런 작업이 머리가 아프기도하고 이게 지금 도메인 단위 모듈로 분리했을떄랑 무슨 차이인지 모르겠기도하고...
제미니님은 도메인 패키지 간의 순환참조에 대해서는 어떻게 해결하시나요?
코드를 보지 못해서 케이스를 제가 정확히 이해하진 못했으나 기본적으로 어떤 구조에서건 `순환 참조`는 피해야하는 것 같습니다!
(적어주신대로 모듈 구조, 패키지 구조 차이 없는 부분 같아요)
해결하는 전략은 케이스 마다 다를 것 같습니다 (예제가 없으니 설명이 다소 어렵네요)
대부분 케이스에선 적어주신 것 처럼 `개념(도메인)` 들에 대해서 의존성을 한 방향으로 하도록 구현을 다지면 순환 참조는 자주 발생하는 것 같지 않습니다,
혹시 문제가 있으신 사례를 각색하여서 알려주시면 더 디테일하게 답변 드려보겠습니다!
@@geminikims
아 그럼 제가 고민했던 부분을 말씀드려볼게요!
결제 - 주문 - 배송 - 배송 부가서비스
이렇게 4가지 개념이 있습니다
저는 주문의 비즈니스 레이어에서 주문을 할 경우 배송 예약 및 배송 부가서비스까지 예약하는 로직을 주문 비즈니스에 나타내고 싶었습니다!
따라서 처음에는 "배송"과 "배송 부가서비스"의 컴포넌트를 가져와서 비즈니스 레이어에 두니 "배송"과 "배송 부가서비스"도 "주문" 개념을 의존하고 "주문" 개념도 이 2가지 개념을 의존하는 순환참조가 발생하게되었습니다.
물론 코드 실행에는 문제가없었지만 마음속에서 찝찝한 마음이 들어 "주문" 개념에 인터페이스를 만들어 의존성 역전을 통해 의존성이 한쪽으로만 흐르도록 만들긴했습니다.
여기서 제가 궁금했던 점은 자연스러운 의존성 방향은 "배송 부가서비스" -> "배송" -> "주문" 이렇게 흐르는게 정상이지만 주문 비즈니스 로직에 "배송 부가서비스"를 예약하는것도 보여주고싶은 저의 욕심으로 "배송 부가서비스"에서 "주문" 개념도 바로 의존하게 되었습니다. 근데 이럴 경우에 인프콘에서 제미니님이 말씀하신 "격벽"을 2개를 뛰어넘어서 "주문"에 바로 의존하게 되는데 이렇게 해도 되는건지 궁금합니다!
참고로 "배송 부가서비스"는 원래는 "배송"개념과 함께였으나 크기가 커질거같아 배송에서 개념을 분리해서 생성되었습니다!
혹시나 참고가 되실까하여 gist 코드 스니펫 링크 남겨볼게요!
gist.github.com/JiwonKKang/5a05ca752fba37b54836d62c624c9de2
설명이 제대로 됐는지 모르겠네요... 미리 부족한 설명 읽어주셔서 감사합니다
@@강지원-j8c
와우 상세한 질문 감사드립니다
우선 영상으로 얘기해보기전에 간단하게만 답변 드려보면
(제 말이 절대 정답은 아닙니다!! 코드 단편만 본 얘기다보니 참고만 해주세요!)
개념의 정석 흐름상으론 "주문 -> 배송 -> 배송 부가서비스" 가 되는 흐름에서
현재 수준이 완전히 "문제" 라고 보기엔 어렵다고 보입니다!
다만 적어주신 것 처럼 "주문" 과 "배송" 사이엔 격벽이 있으면 상당히 관리에 유용할 것 같은데요!
한가지 관점으로 보면 "FullDining" 이 "배송 부가서비스" 인데 "FullDining" 를 "주문 도메인"으로 생각 하시는 것 같아서 이 부분을
다시 생각 해보실 수 있을 것 같습니다!
저도 잘 모르고 적은 것이지만 "FullDining" 이 "배송 부가서비스" 라면 "FullDiningInfo" 은 "배송 개념" 의 하위 이지 않을까요?
그렇다면 격벽을 역으로 넘어서 참조하고 있지는 않은 것 같습니다!
모쪼록 현재 부분 코드로만 봤을때에는 어떤 관점으로 보냐에 따라 다른 부분이기도하고, 현재 수준정도 참조에서는 심각한 문제가 없어보이니 추후 더 큰 오염이 감지 될 때 개선으로 봐도 충분한 부분 같습니다!
----------
좀 더 자세히 살펴보는 얘기는
github.com/geminiKim/dev-practice/issues/82 해당 이슈를 통해 추후 영상으로 얘기해보도록 하겠습니다
상세한 질문 감사드립니다!
오 이번주에 팀 아키텍처 문서 만들려고 했는데 제맘 꽤뚫어 보셨나요.. 몇가지 질문이 있습니다!
1. 레이어 규칙을 정하기전에 개발되었던 모든 프로젝트들도 시간이 날때마다 틈틈히 적용하시나요? 아니면 규칙을 정한 이후 프로젝트에만 적용하시나요?
2. Implement 계층에서 디자인 패턴을 적용할시 implement 계층 안에 strategy 혹은 template 등 디자 인패턴 네이밍 그대로 패키지를 두시나요?
감사합니다!!
1. 프로젝트마다 성질이 다르기 때문에 전체적용을 무조건 하지는 않습니다! 이후 생기는 프로젝트도 기본 룰에서 변화해야할 부분을 점검하면서 조율해나가는 편입니다!
그래서 전체 프로젝트에 일괄 적용하는 식 보다는, 해당 프로젝트 작업을 해야할때 마다 개선 규칙을 적용할게 있나 고민해보는 것 같아요!
2. 요것도 케바케이긴한데 가급적 사용한 패턴을 패키지명으로는 잘 안 쓰려고합니다! 패키지는 개념 기준으로 묶는 편이에요!
다만 관리가 까다롭거나 패턴으로 묶고 구현체를 고립시키는게 더 낫다면 그런 패키징도 가능하다고 생각합니다!
오늘도 봐주셔서 감사합니다! :D
좋은 내용 감사해여 ㅎㅎ
봐주셔서 감사합니다!
좋은 영상 감사합니다
봐주셔서 감사합니다!
커피한잔하기 좋은 길이.
봐주셔서 감사합니다! 이번 주도 화이팅입니다!!