전 ddd도 잘 모르기도하고, 관심도 없고, 그 책도 보지 않아서 잘 모르겠지만, 아마 모듈에 대해서는 설명 안했을 것 같네요. 의견 드릴 수 있는 것은 역할을 중심으로 모듈을 쪼개는 것에 대해서는 충분히 검토를 해보셔야합니다, 대부분의 경우에선 응집을 기준으로 모듈을 쪼개시는데 불필요한 코드나 복잡도를 낮추는 전략인 것 같습니다.
@@geminikims 오잉!? [테스트 주도 개발로 배우는 객체 지향 설계와 실천] 책을 좋아하신다고 하셔서 X-Driven-Development에 전반적으로 관심이 있으신줄 알았어요! 감사합니다! 아직 책을 다 읽기 전이라.. 저도 다 읽어보고 멀티모듈도 성숙해질 때까지 여러번 사용해보고 경험해봐야할거같아요 그나저나 저 이번에 인프콘 가는 4년차 개발자인데.. 만나면 인사나눠요!
TDD는 유일하게 제가 쓰는 약어일 정도로 애정합니다ㅎㅎ (물론 과몰입+광신도들은 여전히 싫지만요...!) 유독 DDD는 광신도가 심한 영역이라 의도적으로 안보는 부분도 있습니다! 잘은 모르지만 DDD 자체는 당연히 좋은 내용일 거라고 생각합니다~ 다만 만병통치약은 아닐 거라는 확신도 있어요! 인프콘 오시는 군요! 인사 나눠요!! (제가 뚝딱거려도 양해 부탁드립니다 후후...)
@user-vz6zf5ee4k 인프콘 후기 블로그 잘 봤습니다.......... 지각하셔서 제 세션을..................................🥲 박제 되셨음을 공유드립니다 :D github.com/geminiKim/dev-practice/issues/79#issuecomment-2278498047
디자인패턴의 오용사례와 비슷하지 않나 싶네요. 디자인패턴도 그 의도를 무시하거나 맞지 않은 상황에서 억지로 맞추거나 일단 사용해보는 맥락과 비슷하지 않나 싶네요. 모듈도 책임이 있는 객체들의 집합이고 그 책임과 역할이 제대로 형성되어 있지 않은 상태에서 무분별하게 멀티모듈로 나눌 경우 안쓰니만 못하다는 의미이신거 같네요. 저는 이런 내용을 보면 객체지향에 대한 이해도가 가장 중요한게 아닌가 생각이 드네요
영상 잘 봤습니다! 감사합니다. 제 경우에는 도메인에 대해 이해도도 충분하고 서비스도 오래 운영하고 있어서 성급한 추상화를 하지 않을 정도라고 생각을 하는데, 간혹 컨퍼런스 영상들을 보면 모듈을 나누는 단위가 다양한 것 같고, 이에 대한 문제들도 많은 회사들이 겪는 것 같더라고요. 그래서 멀티 모듈에 대한 충분한 경험 없이 회사 서비스에 적용을 한다는게 조심스러운 것 같아요. 그런 문제를 감내 할만큼 멀티모듈의 장점이 뚜렷한지도 모르겠구요..그래도 기회가 되면 한번쯤 적용해보고 싶기는 합니다 ㅠ 그리고 여기저기서 잘 분리된 모듈은 하나의 서비스가 될 수 있다는 내용을 몇번 들었던 것 같은데 그래서 아키텍처 = 모듈이라고 생각을 했었나봅니당..
오늘도 재밌게 봤습니다~ 영상 중에 1:37 패키지를 열어주셔서 봤는데 도메인 관련된 부분이 한 뎁스에 쭉 있네요! 하위 패키지로 분리되어있지 않으신데용 이게 지속 성장에서 이야기하셨던 부분인가요? 재밌게 봤습니다. 좋은 한 주 보내세요~ - 혹시 오픈챗 운영하실 생각 없으신지… 궁금합니다~!
이번 영상도 너무 잘 봤습니다 ~~ 듣다 보니 궁금한 게 생겼는데요. 특정 도메인을 별도에 모듈로 분리해도 되겠다 아니면 해야겠다고 판단을 하는 기준이 멀까요? 영상에서 성숙도라고 하신 거 같은데.. 그 성숙도라는 게 무엇인지 좀 더 설명을 듣고 싶습니다. 예를 들자면 예시 프로젝트에서 도메인 하위 qna,review 등이 domain-qna, domain-review 등으로 분리되는 상황입니다.
