인프런 커뮤니티 질문&답변
작성한 질문수
개념 간 격벽을 침범하는 경우
해결된 질문
작성
·
46
1
안녕하세요!
보통 실무를 하다보면 여러 개념이 명확히 떨어지지 않는 경우도 있을 거 같습니다.
예를 들어 예약의 경우는 상품을 고르고, 여러 할인정책이 있고, 쿠폰, 포인트 등 여러 개념이 혼합되어 생기는 개념이라고 생각합니다!
혹시 이런 경우에는 예약도 한 개념이라고 볼 수 있을까요?
그리고 예약이 한 개념이라면 ReservationService를 만들었을 때 ReservationService는 godObject같은 형태가 만들어지기 쉬울 거 같은데, 이런 경우 재민님이라면 어떻게 예약과 다른 개념 간 격벽을 치고, 구현적으로는 어떻게 풀어나갈 것인지 알고 싶습니다!
답변 2
0
안녕하세요! 아주 흥미로운 질문 감사드립니다!
예약 자체가 행위에 기반한다고 볼 수 있겠지만, 일반적으로 예약은 서비스에서 상당히 중요한 부분을 차지하게 되는 것 같습니다
그런 측면에서는 당연히 아주 중요한 개념으로 관리해야할 것 같습니다
예제나 상황이 있어야겠지만 임의적으로 제 과거 경험을 기반하여 말씀드리면
예약을 단순히 예약 개념 하나로 관리하면 안될 것 같습니다
예약 전 상품을 고르고 날짜 및 옵션을 고르는 등 준비 하는 개념이 존재 할 수 있을 것 같고
그 선택 된 것을 최종적으로 예약 완료 처리 하는 개념이 나뉠 수 있을 것 같습니다
또 정확히 보면 예약은 결제 전/후로 나뉠 수 있을 것 같습니다
결제가 완료 되어야 예약을 확일 할 수 있는 것 이기 때문에 이 부분에 대한 고민도 필요할 것입니다.
그래서 종합적으로 보면 예약이라는 큰 그림을 한개의 개념으로 다룰 순 없을 것 같고 (이러면 적어주신 것 처럼 모든걸 다 알게되는 개념이면서 코드도 그렇게 나오겠죠ㅠㅠ)
복합적인 만큼 개념을 더 잘게 쪼개서 명확함을 만드는게 좋을 것 같습니다
가장 쉬운 예로는 예약 준비 -> 예약 완료 상태스럽긴 하지만 이 각각을 개념으로 나누고 격벽을 생성하여 격리시킬 수 있을 것 같습니다
그러면 PreReservation -> Reservation 이런식이 될 수도 있겠죠
(Reservation은 예약을 위한 정보를 PreReservation 통해서 참조하도록 할 수도 있을것 같습니다, 다만 외부 API 통해 예약을 하긴해야하니 이 부분은 구현 각을 봐야할 것 같아요!)
아무래도 특정 상황으로 지칭해야 더 명확히 답변드릴 수 있을텐데, 느낌이 적절히 전달되었으면 좋겠네요!
아주 좋은 고민을 하고 계신 것 같아서 더 많이 고민해보시길 바랍니다!
모쪼록 도움이 되었길 바라며 완강까지 잘 부탁드리고 수강평도 기대하겠습니다!
감사합니다!
어느정도 의문을 푸시는데 도움이 되었다면 다행입니다!
개념을 적절한 단위로 나누는 것은 정말 답이 없기 때문에 많은 고민과 시도가 필요합니다!
(고민이 많이 되실땐 좀 시간이 들어도 최소 3개 버전의 코드를 만들어 보시고 객관적으로 셀프 비판을 가미해서 비교해보시면 제일 좋습니다!)
이번 강의를 통해서 충분히 고민해보시고 적절한 개념 정리 방식인지 고민이 되신다면
편하게 언제든 질문 부탁드립니다! 😃
예약 케이스는 제가 어떤 상황에 계신지 정확하게 몰라서 약간 뜬구름일 수 있지만, 약간 더 디테일한 예시를 적어주시면 더 자세히 답변 드리겠습니다!
감사합니다!
0
안녕하세요, 인프런 AI 인턴입니다.
우으어으님이 말씀하신 것처럼 실무에서는 여러 개념이 혼합되어 하나의 큰 개념으로 표현되는 경우가 많습니다. 예약 시스템에서도 상품, 할인, 쿠폰, 포인트 등의 다양한 요소가 함께 작용합니다.
예약 개념의 이해
- 예약을 하나의 개념으로 볼 수 있는가?
- 예약은 여러 구성 요소의 종합적인 결과물로 볼 수 있습니다. 즉, 예약 자체도 하나의 주요 도메인 개념으로 간주할 수 있습니다. 이 때, 개별 요소보다 전체적인 흐름을 관리하는 것이 중요합니다.
- 예약은 여러 구성 요소의 종합적인 결과물로 볼 수 있습니다. 즉, 예약 자체도 하나의 주요 도메인 개념으로 간주할 수 있습니다. 이 때, 개별 요소보다 전체적인 흐름을 관리하는 것이 중요합니다.
God Object 방지 및 구현 전략
작게 나누기:
ReservationService가 복잡성과 책임이 비대해지지 않도록, 예약의 각 기능을 작은 서비스나 모듈로 나누는 것이 중요합니다. 예를 들어,DiscountProcessor,CouponApplier,PointManager등의 클래스를 만들어 각 기능을 분리할 수 있습니다.
여러 레이어로 관리:
- 각 서비스는 자신의 기능만을 책임지도록 하고,
ReservationService는 이러한 서비스를 조합하여 전체 예약 프로세스를 관리하는 역할만 하도록 합니다.
- 각 서비스는 자신의 기능만을 책임지도록 하고,
설계 패턴 적용:
- 각 기능을 설계 패턴에 맞게 구현하면, 각 객체의 책임과 역할이 명확해집니다. 예를 들어, 전략 패턴(Strategy Pattern)을 사용하여 다양한 할인 정책을 적용할 수 있습니다.
- 각 기능을 설계 패턴에 맞게 구현하면, 각 객체의 책임과 역할이 명확해집니다. 예를 들어, 전략 패턴(Strategy Pattern)을 사용하여 다양한 할인 정책을 적용할 수 있습니다.
관련 게시물에서 추가적인 관점과 구체적인 구현 예를 도움 받을 수 있습니다. 아래 링크를 참고해 주세요.
- Controller에서 비즈니스 로직 흐름이 나타나는 것에 대하여.. - 서비스 계층의 책임을 어떻게 나눌지에 대한 논의가 포함되어 있습니다.
- 도메인 계층에서 Page 사용 질문 - 도메인 계층 설계 시 순수성 유지와 여러 개념 간의 격벽을 치는 방법에 관한 논의를 확인할 수 있습니다.
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.
제가 질문을 너무 추상적으로 드린 건 아닌가 걱정했는데, 이렇게 자세하게 답변 주셔서 정말 감사드립니다!
말씀해주신 내용을 읽고 나니, 개념을 언제, 어떻게 나누어야 하는지에 대해 더 깊이 고민해봐야겠다는 생각이 들었습니다.
그동안은 눈에 보이는 큰 단위 중심으로 서비스와 개념을 구성하다 보니, 하나의 서비스가 점점 비대해지고 막상 쪼개야 할 시점이 되면 어디서부터 나눠야 할지 막막하더라구요.
또, ‘개념’이라는 게 단순히 명사적인 객체로만 존재하는 게 아니라,
행위나 과정 자체로도 정의될 수 있다는 생각이 들었습니다!
말씀 주신 내용을 참고해서, 앞으로는 제가 작성한 코드들을 보며
각 개념을 어떻게 더 명확하게 구분할 수 있을지 고민해보려고 합니다.
다시 한번 좋은 답변 해주셔서 감사합니다!