인프런 커뮤니티 질문&답변
작성한 질문수
강의를 보고 궁금한 것 질문 드립니다!
작성
·
55
1
안녕하세요 🙂 지난번에 이어 질문을 또 남기게 되었습니다 ㅎㅎ
1. Point 라는 개념을 다룰 때 PointService에서 로직을 처리하지 않고 별도의 PointHandler라는 객체를 만들어서 처리하는게 Point 개념 자체가 다른 개념에서도 많이 사용하는 개념이다보니 PointService에서 처리하게 되면 Service 간 참조가 생기는 것을 방지(?) 하고자 이런 전략으로 처리한 것일까요?
이런 식으로 격벽을 넘어서 여러 개념에 걸쳐 있는 개념을 다룰 때는 별도로 분리해놓는 것이 재사용성, 응집 측면에서 좋은 전략인지 궁금합니다!
2. 지금 Point 변화를 주는 것을 PointBalanceEntity 에서 처리하고 있는데 만약 추후에 복잡한 포인트 적립 정책이 생긴다면 별도의 PointPolicy 를 Object 클래스로 만들어 해당 클래스에 포인트 적립 관련 로직을 응집 시키는 식으로 PointPolicy 라는 개념을 추가하는 건 어떻게 생각하시는지 궁금합니다!
감사합니다😀
답변 2
0
안녕하세요! 또 질문 주셔서 감사합니다!
1.
맞기도하고 아니기도합니다ㅎㅎ 우선 Service 참조를 막기 위한 것은 의도가 아예 없는 것은 아니지만 부수적인 이득이라고 생각하구요!
근본적으로는 포인트 사용 자체는 비즈니스성 보다는 타 비즈니스에서 활용 되는 목적이기 때문에 Service 레벨의 구현 보다는 구현체 자체로 존재하여 활용도가 높게 존재하고자 하는 의도가 제일 중요한 의도입니다!
부가적으로 적어주신 것 처럼 여러 개념에 걸쳐있으면 재사용성/응집이 좋은 경우가 많습니다!
다만 유의해야 할 것은 단순히 여러 개념에 걸쳐있다가 클래스를 분리하는 기준이 되면 안 될 것 같습니다!
클래스 분리는 역할과 책임 관점에서도 적절한가? 과하지 않은가? 에 대하여 검토한 후 쪼개는 방향이 좋을 것 같습니다!
(개념과 격벽은 요구사항과 코드를 융합하여 나타내는 형태인 것이지, 반대로 개념과 격벽 기준으로 코드가 작성 되면 안되는 느낌이라 봐주셔도 좋습니다!)
2.
요구사항에 따라 다를 것 같지만 적립 정책이 복잡해지고 동적으로 처리 되어야한다던가하면 자연스럽게 클래스 추가는 괜찮을 것 같습니다!
모쪼록 답이 되었길 바라며 완강까지 화이팅입니다!
수강평도 기대하겠습니다! 감사합니다!
앗....! 강의에서도 설명을 했던 것 같은데요! 강조해서 설명을 하지 않았던 것 같기도해서 말씀드리겠습니다!
개념과 격벽을 바탕으로 요구사항을 추상화(?) 해서 이걸 코드로 구현한다고 생각을 했습니다.
적어주신 것은 사실 제가 강의에서 의도한 것은 아닙니다!
강의의 순서와도 의미가 같지만 개념도를 활용하는 전략은요구사항 분석 -> 개념도 작성 -> 구현 이 순서가 아닙니다!요구사항 분석 -> 구현 -> 개념도 반영 이게 제가 보통 활용하는 전략입니다!
저는 대부분 경우 개념도를 기획/디자이너 타 직군들도 다 볼수 있게 팀에 오픈해둡니다
(그들이 열심히 보냐는 다른 문제지만요...ㅎㅎ)
그래서 실제 우리가 만드는 소프트웨어의 요구사항과 구현을 투영하는 것을 개념도로 작성하여 둡니다!
느낌을 좀 더 명확하고 짧게 요약해보면
개념과 격벽을 먼저 생각하고 구현하는 것이아니라
개념과 격벽을 추상화(?) -> 구현 = 제가 권장하는 것이 아님
요구사항을 충분히 이해하고 구현하면서 (구현하면서 개념과 격벽을 느낌) 개념도를 그린다
구현 하면서 개념과 격벽을 생각 = 제가 권장하는 것
이런 느낌이라고 봐주시면 좋을 것 같습니다!
적어주신 것이 틀렸다기 보다는 아주 미묘한 뉘앙스 차이가 있으니 이 점을 한번 생각해보시면 좋을 것 같습니다!
제가 위에 답글에서 저 말씀을 드린 이유는 단순히 개념과 격벽 기준으로만 생각해서 여러 개념이 붙었단 이유로 클래스를 분리하면 안 된다는 걸 부연 설명하려했습니다!
클래스 분리는 역할과 책임 관점에서도 적절한가? 과하지 않은가? 에 대하여 검토한 후 쪼개는 방향이 좋을 것 같습니다!
이것도 동일한 설명이였구요!
추가로 이 전략 자체도 제가 정의한 개념도 라는 것을 활용하는 전략이므로 이게 절대적 법은 아닙니다! 비가싫어요님만의 전략을 구축하셔도 좋겠습니다!
모쪼록 답이 되어서 도움이 되었길 바랍니다!
0
안녕하세요, 인프런 AI 인턴입니다. 비가싫어요님.
PointHandler사용의 이유
개념적으로 Point와 같은 도메인은 여러 다른 서비스에서 공통적으로 사용될 수 있습니다. PointService에서 모든 로직을 처리하게 되면 다른 서비스와의 의존성이 높아져 결합도가 증가할 수 있습니다. 반면, PointHandler와 같은 객체를 별도로 설정하여 해당 개념을 처리하게 하면 특정 서비스에 종속되지 않고, 독립성을 유지할 수 있습니다. 이러한 방식은 높은 응집도와 낮은 결합도를 유지하는 데 도움이 됩니다. 따라서 서비스 간의 참조를 최소화하고, 재사용성을 높이는 데 유리한 전략입니다.
PointPolicy도입 제안
포인트 적립 정책이 복잡해질 경우, 별도의 PointPolicy 객체를 만들어 관련 로직을 응집시키는 것은 매우 논리적이고 확장 가능한 접근 방식입니다. 이렇게 하면 포인트 정책을 분리하여 관리하기 쉬워지고, 정책 변경 시 다른 부분에 미치는 영향을 최소화할 수 있습니다. 따라서 PointPolicy와 같은 개념을 도입하는 것은 코드의 유지보수성과 확장성을 향상시키는 좋은 방법입니다.
관련하여 참고할 수 있는 게시물로는 Service 간 의존하는 경우 를 추천드립니다. 이 게시물을 통해 서비스 간 의존성을 최소화하면서도 관리할 수 있는 전략의 구체적인 사례를 볼 수 있습니다.
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.
안녕하세요! 답변 감사드립니다. 답변해주신 내용 중에 이해가 잘 되지 않는 것이 있어 답글 남깁니다 ㅎㅎ
개념과 격벽은 요구사항과 코드를 융합하여 나타내는 형태인 것이지, 반대로 개념과 격벽 기준으로 코드가 작성 되면 안되는 느낌이라 봐주셔도 좋습니다!
말씀해주신 이 부분이 잘 이해가 되지 않는데요. 저는 개념과 격벽을 바탕으로 요구사항을 추상화(?) 해서 이걸 코드로 구현한다고 생각을 했습니다. 그런데 개념과 격벽을 기준으로 코드가 작성 되면 안 된다고 하시니 제 이해가 잘못된 것 같습니다.
조금 더 설명을 부탁드려도 괜찮을까요?