인프런 커뮤니티 질문&답변
작성한 질문수
격벽의 순환 참조(?)
작성
·
22
1
안녕하세요. 지난번에도 질문 남겼었는데 또 찾아뵙게 되었습니다.
user 의 경우 많은 개념들이 참조하게 될 것 같습니다.
회원탈퇴라는 기능이 제공될 때, 회원이 탈퇴되면 관련된 개념들을 삭제해야된다고 할 경우 이를 어떻게 해결하는 것이 좋을까요?
user 쪽에서 관련 개념들을 찾아서 삭제하기에는 개념 격벽간의 순환 참조(?)가 발생하게 될 것 같습니다.
카프카나 메시지 큐 등을 이용해서 처리할 수 있을 것 같은데 현재 이를 처리할 수 있는 별도의 인프라는 없다고 가정해보고 싶습니다.
그렇다면 어플리케이션 이벤트(ApplicationEventPublisher)를 사용하는 것이 방법이 생각납니다.
하지만 이벤트를 사용하게 되면 어플리케이션의 로직 흐름을 보기가 조금 어려우지는 것 같다는 생각도 들어서 괜찮은 방법인지 고민이 됩니다.
답변 2
0
안녕하세요 질문 감사드립니다!
상황에 따라 다르지만 어플리케이션 이벤트의 사용은 적절한 방법이 될 수 있습니다!
회원 탈퇴 이벤트 발행 >> 각 개념에서 이벤트 수신 후 처리
이 방식은 만약 탈퇴 후 처리가 여러 개념에 많다면 충분히 의존성을 끊고 관심사를 분리할 수 있는 전략이라고 봅니다 😃
다른 전략 하나로는 인터페이스를 활용할 수 있다고 봅니다 UserWithdrawalPostProcessor 같은 인터페이스를 만들어두고, 각 개념에서 UserWithdrawalPostProcessor에 대한 구현체를 다 만들도록 한 후
UserService 에선 탈퇴 처리 시 List<UserWithdrawalPostProcessor> 를 주입 받아 로직을 순회하여 돌리는 방법도 가능하다고 봅니다
이렇게 되면 직접 접근하는 것 보다는 느슨한 의존(직접 아는 것은 아님)을 갖고 있기 때문에 어느정도 괜찮은 전략 중 하나라고 봅니다 😃
다만 강의에서 중간에 스치듯 언급했지만, User는 전역적인 개념 수준입니다, 몇몇 개념을 제외하고 모든 것을 알고 연관되어 있죠 😀
그렇다보니 사실 회원 탈퇴 구현 도구를 만들고 그 곳에서 대부분 개념에 접근해서 탈퇴처리를해도 문제가 없다고 생각합니다!
이미 User를 개념도에 그려보면 그 순간 격벽간 순환 참조는 바로 보이게 됩니다 (이미 순환 참조인거죠ㅎㅎ)
그래서 결국 탈퇴 후 처리 로직의 규모를 보고 구현 전략을 정의하시면 좋을 것 같습니다!
모쪼록 답이 되었길 바랍니다! 감사합니다! 😃
유튜브에서 다룰만한 주제 같아서 추후에 유튜브에서도 얘기해보겠습니다!
이슈 : https://github.com/geminiKim/dev-practice/issues/151
0
안녕하세요, 인프런 AI 인턴입니다. 심플스택님.
회원 탈퇴 시 관련된 개념들을 삭제하는 문제는 다소 복잡할 수 있으며, 특히 여러 도메인이나 개념이 얽혀 있는 경우 격벽으로 인해 순환 참조 이슈가 발생할 수 있습니다. 이를 해결하기 위해 이벤트 기반 아키텍처나 직접적인 참조를 피하는 방법을 고려할 수 있습니다.
문제 해결을 위한 제안
어플리케이션 이벤트(ApplicationEventPublisher):
- 이벤트 기반으로 처리하면, 각 도메인이 독립적으로 이벤트에 반응하여 자신의 관련 데이터를 처리할 수 있습니다. 이를 통해 격벽을 침범하지 않고도 다른 개념의 변화에 대응할 수 있습니다.
- 이벤트 사용의 단점으로는 코드 흐름이 모호해질 수 있다는 점이 있지만, 이를 해결하기 위해선 적절한 이벤트 명명 및 강력한 로깅이 필요합니다.
- 이벤트 기반으로 처리하면, 각 도메인이 독립적으로 이벤트에 반응하여 자신의 관련 데이터를 처리할 수 있습니다. 이를 통해 격벽을 침범하지 않고도 다른 개념의 변화에 대응할 수 있습니다.
관리 서비스 또는 유틸리티 클래스:
- 특정 관리 서비스에서 전체 항목을 조율하여 이를 삭제하도록 하는 방법입니다. 이 경우 애플리케이션 레이어에서 모든 관련 개념을 알고 있는 하나의 매니저가 존재할 수 있으며, 이를 통해 오케스트레이션할 수 있습니다.
- 특정 관리 서비스에서 전체 항목을 조율하여 이를 삭제하도록 하는 방법입니다. 이 경우 애플리케이션 레이어에서 모든 관련 개념을 알고 있는 하나의 매니저가 존재할 수 있으며, 이를 통해 오케스트레이션할 수 있습니다.
연관 데이터의 비활성화:
- 즉각적인 삭제 대신, 관련 데이터를 ‘비활성화’ 상태로 전환하여 추가적인 조건을 통해 접근을 차단하는 방법도 검토할 수 있습니다. 이는 데이터의 삭제로 인한 예기치 못한 오류를 방지하며, 지속적인 트랜잭션 롤백 문제를 피할 수 있습니다.
- 즉각적인 삭제 대신, 관련 데이터를 ‘비활성화’ 상태로 전환하여 추가적인 조건을 통해 접근을 차단하는 방법도 검토할 수 있습니다. 이는 데이터의 삭제로 인한 예기치 못한 오류를 방지하며, 지속적인 트랜잭션 롤백 문제를 피할 수 있습니다.
추가적으로 이와 관련한 다른 수강생의 질문 및 답변을 살펴보시면, 유사한 고민을 다룬 사례를 찾을 수 있습니다:
- 적절한 도메인 서비스의 이용과 데이터 관리 전략: 이벤트와 서비스 사용에 대한 논의를 참고해보세요.
- 격벽 내에서의 참조와 응집도를 높이는 전략: 도메인 객체 간의 참조와 의존성 관리에 대해 논의합니다.
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.