인프런 커뮤니티 질문&답변
작성한 질문수
섹션2에서 Product와 Category 간 개념 정리에 대해 질문이 있습니다 !
해결된 질문
작성
·
143
·
수정됨
1
제미니님 안녕하세요 !
강의 수강 중 Product와 Category간 개념 정리네 대해 질문이 있습니다 !
강의를 들으면서 Product와 Category에서 Product가 상위의 개념이라고 선택하시고 매핑 테이블을 네이밍을 ProductCategory을 사용하셨다고 이해하고있습니다 !
그런데 개념도를 봤을때.. 개념 간 매핑해주는 ProductCategory가 Product 개념 영역에 있는게 맞는지 의문이 들었습니다 !
Category가 Product 하위의 부가적인 정보로서 ProductCategory가 Product 개념 영역에 존재할 수도 있지만.. 강의에서 설계하는데 있어 Product가 상위 개념으로 판단을 했고, ProductCategory는 Category에 대한 부가정보인데 상위 개념이 하위 개념에 대한 것을 모르도록하는게 맞지 않나 라는 생각이 들어서 질문드립니다 !
답변 1
2
우용님 아주 흥미로운 질문 감사드립니다!
우선 Product 와 Category 관계에서 상/하위를 비교해서 말씀드렸지만
정확히하면 개념도는 평면도 개념이기에 위상으로 비교하는게 큰 의미는 없습니다 (상/하위란 것도 둘의 연관성과 별개로 거리감을 보여주는 것이라고 이해하시면 좋습니다)
더 중요한건 개념간의 거리/연관도 그리고 더더 중요한건 개념들의 중요도(우선도) 정도라고 볼 수 있을 것 같습니다
적어주신 의문 중 먼저 다시 짚어봐야하는 부분은 ProductCategory 는 Category 에 대한 부가정보라고 볼 수도 있고, 아닐수도 있습니다
왜냐하면 ProductCategory 은 Product 와 Category 를 모두 알고 있기 때문입니다
(개념도에서 ProductCategory -> Product 화살표가 없는 것은 같은 격벽 안에 있기 때문입니다)
그러므로 ProductCategory 는 사실 어디에도 존재할 수 있습니다, 반대로 클래스 이름도 CategoryProduct 으로 해도 불가능한 것은 아니라는거죠
그렇다면 무엇을 기준으로 개념도를 그린 것 일까요?
제가 개념도를 그리는 기준은 일반적으로 중요도 입니다, Category 는 이번 강의 기준으론 사실 최종 개념도에 생략 될 정도로 중요한 개념이 아닙니다
반면에 Product 는 중심에 있는 개념입니다, 그만큼 지금 우리가 만드는 서비스 기준으론 Product 중심으로 비즈니스가 돌아가는 부분이 있다는거죠
그 관점에서 ProductCategory 같이 모호한 친구를 어디 둘것인가에 대해서는
결국 "카테고리가 연결 된 상품 정보 vs 상품이 연결 된 카테고리 정보" 이런 상황인 것이고 여기서는 어디에/어떤기준으로 일관적으로 무게를 둘것인지 선택만 필요할 뿐인것이죠!
사실 Product 와 Category 는 서로 관심도 없고 굉장히 먼 사이입니다 (상/하위를 떠나서 서로 알고 싶어하지 않고 관심도 없고, 거리가 먼 상태)
마치 레이어 처럼 상/하위로 나타내기 불가능한 상태이기도합니다
Product 가 Category 가 있어야지만 생성 될수있다던가
Category 가 Product 가 있어야지만 생성 될수있다던가
위와 같은 상황이 아니니까요!
그래서 개념도 상으로도 "Product 하위에 Category 가 있다" 라고 이해하시면 안 됩니다!
(다만 우용님만의 새로운 개념도 그리기 기준을 만드신다면 가능한 부분입니다! 강의 기준으로 의도한 내용은 그렇지 않습니다는 얘기입니다ㅎㅎ)
대략 이런 느낌이 존재하는거죠
Product 와 Category 는 서로 관심도 없다
Product 와 Category 는 서로의 존재도 모른다
요구사항의 의해 Product 마다 Category 가 존재 할 수있어야한다, 그런데 Product 는 이 사실을 알고싶지않다
현재 우리 서비스에서 Product 는 1급 개념
현재 우리 서비스에서 Cateogry 는 9급 개념
우리 비즈니스의 개념을 정리해보니 Product 중심이기에 중심 개념 기준으로 개념을 모아두었다
+@ 사실 강의 초반 설명을 위해 개념도에 그려두었지만 ProductCategory 수준은 개념도에 그리지 않는게 맞습니다! 별로 중요한 개념은 아니거든요!
용어적으로 제가 혼동을 드린 부분도 있어보여서 참고하셔서 한번 더 생각 해보시면 좋을 것 같습니다!
보통 저는 개념의 급수라고 표현을 하기도하는데 상/하위보다는 1급개념, 2급개념 이런식으로 관리하는 것 같습니다!
(관련 제 유튜브 영상 : https://www.youtube.com/watch?v=H6f0VfbXcb4)
개념도는 그리기 나름이지만 제 경우는 평면으로 그리기에 위상은 없는 형태라고 봐주시면 됩니다!
더 궁금하신거나 이해가 더 필요하신 부분이 있다면 편하게 답글주세요!
누구나 생각해볼법한 흥미로운 질문 감사드립니다 우용님! 남은 강의도 즐거운 시간 되시고 완강 후 수강평 부탁드려요!
scorbiclife님 질문 감사드립니다!
먼저 강의에서 언급을 몇번 했던 것 같긴한데 저 같은 경우는 ProductFinder 와 같은 컴포넌트(도구)들은 개념도에 작성하지 않습니다!
일반적으로 생성 된 클래스들을 1:1로 개념도에 투영하게 되면 개념도의 복잡도가 상당히 많이 올라가게 되기 때문입니다
(부가적으로 비개발 직군이 볼때도 더 이해하기 어려워지기도합니다, 제 경우는 기획자 디자이너에게도 개념도를 공유하는 스타일이라, 가급적 컴포넌트는 넣지 않습니다!)
다만 정~말 중요하고 이건 사내에서 누구한테 말해도 다 알아야하는 수준의 비즈니스를 투영하는 개념이라면 검토해볼 수 있다고 생각합니다
(다만 이걸 개념도를 처음 보는 사람들이 아 이건 코드랑 1:1 매핑되는구나? 라고 생각 할 수 있기 때문에 이것에 대한 공유와 관리가 필요할 것 같습니다, 잘 못하면 클래스 다이어그램하고 별반 차이가 없어집니다)
그렇기 때문에 만~약 넣더라도 ProductFinder 처럼 코드를 투영해서 넣는 것 보다는 행위에 대해서 표현하는 식으로 하시길 추천드립니다
(행위에 대해서는 모양이 다른 동그라미 도형을 쓴다던가, SerachProduct 이런 행위 기반을 명명을 개념도에서 한다던가의 전략이 좋아보입니다)
다만 이것은 제가 대부분의 경우 사용하는 개념도 작성 전략이기에 고민해보시면 좋을 것 같습니다, 결국 나만의 개념도(or 다른 이름) 작성하기를 해내야하니까요!
혹시
ProductFinder는 개념도 상에 들어갈 만한 중요도의 개념인가요?ProductCategory대신 넣고 싶어서 질문드렸습니다!추가: 제가 이렇게 생각하게 된 이유는 다음과 같습니다.
Finder들이 얼마나 중요한 의미를 내포하고 있는지 확실하지 않지만 무언가를 검색한다는 것이 업무 상 의미가 있는 개념이라고 생각했습니다.
(Product, Category) 매핑 자체가 현재 상황에서는 업무를 할 때 꼭 알아야 하는 개념이 아니라고 판단했습니다.
현재 ProductCategoryEntity에 id 외의 별도의 정보가 들어 있지 않고, ProductCategoryRepository도 탐색에 도움을 주는 메소드들만 있기 때문입니다.
추가: 다음은 추가하지 말아야 할 이유입니다.
의존 관계 상 ProductFinder가 의존하고 있는 중요하지 않은 클래스가 너무 많네요
ProductFinder를 개념도에 넣으면 ProductFinder가 만능 객체가 될 가능성이 있어 보입니다.