이렇게 N개의 runnable을 만들 때 CI는 어떻게 태우시나요? 예를 들어 github action을 쓴다고 했을 때 on을 어떻게 관리하는지 궁금합니다! runnable 별 별도의 workflow를 다 분리하는지? 아니면 분기처리를 하는지 등등! 특히 push event 에 바로 동작한다면 어떤 것을 빌드할 지 결정해줘야 하는데 어떤 아규먼트를 던지는지 궁금합니다
Runnable이 두 개인 경우 storage-core, storage-admin 이렇게 db 쪽 모듈을 나누시는 편인가요? runnable 에따라 domain은 나눴는데 (syncer, querier) db 모듈은 공유해서 쓰려고 하니 db 모듈의 볼륨이 커지는 느낌이고 나누자니 그냥 별도의 프로젝트 느낌이 들면서 이게 조합가능한 모듈링인가? 라는 의문이 드네요 개인적으로 멀티모듈은 조합 가능한 형태로 나오는 것이 좋다 생각하는데 db-core db-admin은 각 runnable에 종속된 느낌입니다. 제민님은 어떻게 생각하시나요
@@geminikims 안녕하세요 제민님 말씀 듣고 db 모듈은 분리하지 않고 작업을 하고 있습니다. 그런데 문제가 생겨 조언을 얻고자 질문드립니다 1. db-core를 나누지 않고 domain만 각각 나눠져 있으면 db-core에는 a-domain, b-domain 의 Repo 구현체를 모두 가지게 됩니다! (compileOnly로 해둠) 2. 이 상태에서 각각의 API 모듈에서는 implement던 runtime이던 하나의 Jar를 만들기 위해 db-core 의존성을 추가하게 될 경우!! A-API 모듈에선 B 도메인은 모르는데 B 도메인의 구현체가 포함됩니다. 이는 db-core에는 B 도메인도 알고 있고 B 도메인의 구현체가 존재하기 때문입니다. 이로 인해 Bean을 찾지 못해서 런이 되지 않고 또 원하는 것만 컴팩트하게 모으고자 하는 모듈화의 의도와도 멀어지는 것 같습니다! 이렇게 두 개의 러너블을 이렇게 띄우는 것은 아닌 것 같은데 보통 어떻게 하시나요?
bean을 못 찾는 에러가 발생한다면 의존성이나 의존 방향의 구성을 잘 못하셨을 가능성이 높습니다. 만약 디비 모듈을 하나로 구성하겠다면 그 모듈은 구현체 덩어리 집합이 되게 해야할 것이고, 직관성이 더 중요하단 판단이면 분리하시는게 맞을 겁니다, 결국 현재 시스템과 요구사항을 정확히 이해해야 판단할 수 있는 부분입니다. 원하시는 구성의 우선순위(직관성, 효율성, 정확성 등등)를 정하시고 거기에 맞는 구성을 선택해보세요
잘 보고 갑니다!
봐주셔서 감사합니다!
오... 좋은내용 감사합니다 : ]
봐주셔서 감사합니다!😃
이렇게 N개의 runnable을 만들 때 CI는 어떻게 태우시나요?
예를 들어 github action을 쓴다고 했을 때 on을 어떻게 관리하는지 궁금합니다!
runnable 별 별도의 workflow를 다 분리하는지? 아니면 분기처리를 하는지 등등!
특히 push event 에 바로 동작한다면 어떤 것을 빌드할 지 결정해줘야 하는데 어떤 아규먼트를 던지는지 궁금합니다
상황에 맞춰서 적절히 나누면 될 것 같습니다
push 시에 유효성과 테스트를 검증하고 싶다면 프로젝트 한번 전체를 돌리면 될 것 같고
환경 배포 시에는 runnable 별로 별도 파이프라인을 만들어서 배포하면 될 것 같습니다
Runnable이 두 개인 경우 storage-core, storage-admin 이렇게 db 쪽 모듈을 나누시는 편인가요?
runnable 에따라 domain은 나눴는데 (syncer, querier) db 모듈은 공유해서 쓰려고 하니 db 모듈의 볼륨이 커지는 느낌이고 나누자니 그냥 별도의 프로젝트 느낌이 들면서 이게 조합가능한 모듈링인가? 라는 의문이 드네요 개인적으로 멀티모듈은 조합 가능한 형태로 나오는 것이 좋다 생각하는데 db-core db-admin은 각 runnable에 종속된 느낌입니다.
제민님은 어떻게 생각하시나요
경우에 따라 다르지만 runnable 마다 디비 모듈을 분리하는 건 좋은 방식 같지는 않습니다
다만 어드민 자체는 근본적 성질이 다를 수 있고 데이터 조회가 더 복잡 할 수 있기 때문에 다른 구조(어드민 모듈이 직접 디비접근)가 허용 가능 하다고 봅니다
@@geminikims 안녕하세요 제민님 말씀 듣고 db 모듈은 분리하지 않고 작업을 하고 있습니다. 그런데 문제가 생겨 조언을 얻고자 질문드립니다
1. db-core를 나누지 않고 domain만 각각 나눠져 있으면 db-core에는 a-domain, b-domain 의 Repo 구현체를 모두 가지게 됩니다! (compileOnly로 해둠)
2. 이 상태에서 각각의 API 모듈에서는 implement던 runtime이던 하나의 Jar를 만들기 위해 db-core 의존성을 추가하게 될 경우!! A-API 모듈에선 B 도메인은 모르는데 B 도메인의 구현체가 포함됩니다. 이는 db-core에는 B 도메인도 알고 있고 B 도메인의 구현체가 존재하기 때문입니다.
이로 인해 Bean을 찾지 못해서 런이 되지 않고 또 원하는 것만 컴팩트하게 모으고자 하는 모듈화의 의도와도 멀어지는 것 같습니다! 이렇게 두 개의 러너블을 이렇게 띄우는 것은 아닌 것 같은데 보통 어떻게 하시나요?
bean을 못 찾는 에러가 발생한다면 의존성이나 의존 방향의 구성을 잘 못하셨을 가능성이 높습니다.
만약 디비 모듈을 하나로 구성하겠다면 그 모듈은 구현체 덩어리 집합이 되게 해야할 것이고,
직관성이 더 중요하단 판단이면 분리하시는게 맞을 겁니다, 결국 현재 시스템과 요구사항을 정확히 이해해야 판단할 수 있는 부분입니다.
원하시는 구성의 우선순위(직관성, 효율성, 정확성 등등)를 정하시고 거기에 맞는 구성을 선택해보세요
이렇게 영상으로도 답변해주셔서 감사드립니다 :) 초반 영상부터 쭉 달리면서 덕분에 멀티 모듈에 대한 인사이트를 계속 쌓아가고 있습니다. 그럼 무더위 조심하시고 야근 없는 한 주 되시길 바라겠습니다..! 🥳
질문 감사드리고 도움이 되었다니 다행입니다! 멀티 모듈 또한 필요할때 쓰는 도구인 것 꼭 참고 부탁드리고요! 😀 이슈 없는 한 주 되세요!