강의를 보고 궁금한 것 질문 드립니다!

안녕하세요 🙂 지난번에 이어 질문을 또 남기게 되었습니다 ㅎㅎ

1. Point 라는 개념을 다룰 때 PointService에서 로직을 처리하지 않고 별도의 PointHandler라는 객체를 만들어서 처리하는게 Point 개념 자체가 다른 개념에서도 많이 사용하는 개념이다보니 PointService에서 처리하게 되면 Service 간 참조가 생기는 것을 방지(?) 하고자 이런 전략으로 처리한 것일까요?

이런 식으로 격벽을 넘어서 여러 개념에 걸쳐 있는 개념을 다룰 때는 별도로 분리해놓는 것이 재사용성, 응집 측면에서 좋은 전략인지 궁금합니다!

2. 지금 Point 변화를 주는 것을 PointBalanceEntity 에서 처리하고 있는데 만약 추후에 복잡한 포인트 적립 정책이 생긴다면 별도의 PointPolicy 를 Object 클래스로 만들어 해당 클래스에 포인트 적립 관련 로직을 응집 시키는 식으로 PointPolicy 라는 개념을 추가하는 건 어떻게 생각하시는지 궁금합니다!

감사합니다😀

안녕하세요, 인프런 AI 인턴입니다. 비가싫어요님.

PointHandler 사용의 이유

개념적으로 Point와 같은 도메인은 여러 다른 서비스에서 공통적으로 사용될 수 있습니다. PointService에서 모든 로직을 처리하게 되면 다른 서비스와의 의존성이 높아져 결합도가 증가할 수 있습니다. 반면, PointHandler와 같은 객체를 별도로 설정하여 해당 개념을 처리하게 하면 특정 서비스에 종속되지 않고, 독립성을 유지할 수 있습니다. 이러한 방식은 높은 응집도와 낮은 결합도를 유지하는 데 도움이 됩니다. 따라서 서비스 간의 참조를 최소화하고, 재사용성을 높이는 데 유리한 전략입니다.

PointPolicy 도입 제안

포인트 적립 정책이 복잡해질 경우, 별도의 PointPolicy 객체를 만들어 관련 로직을 응집시키는 것은 매우 논리적이고 확장 가능한 접근 방식입니다. 이렇게 하면 포인트 정책을 분리하여 관리하기 쉬워지고, 정책 변경 시 다른 부분에 미치는 영향을 최소화할 수 있습니다. 따라서 PointPolicy와 같은 개념을 도입하는 것은 코드의 유지보수성과 확장성을 향상시키는 좋은 방법입니다.

관련하여 참고할 수 있는 게시물로는 Service 간 의존하는 경우 를 추천드립니다. 이 게시물을 통해 서비스 간 의존성을 최소화하면서도 관리할 수 있는 전략의 구체적인 사례를 볼 수 있습니다.

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.

인프런 커뮤니티 질문&답변