관련 Issue & PR
마지막 미션 중 느낀 개선 사항
지금까지 연관관계 매핑으로 직관성을 추구했다. 하지만 극단적이면 탈이 나는 법이다.
조영호님은 '연관관계 매핑은 DB단에서 어떻게 돌아가는지를 잊게 만든다' 라고 하신다.
나도 잠시 이 부분을 망각하고 있었다.
실제로 객체를 표현할 땐 연관관계 매핑을 통해 DB를 거의 신경쓰지 않고, 객체에만 집중해 구현할 수 있었기 때문이다.
이게 굉장히 큰 장점이라고 생각했고, 굉장히 매료되어 있었다.
하지만 분명 객체 매핑으로 표현하기 어려운 것들이 존재했고, DB 조회 성능 측면에서 손해보는 상황들도 있었다.
기술이란건 트레이드 오프를 완화해주는 것이다.
하지만 나는 트레이드 오프를 무시하고 도메인을 객체로 표현하는 데만 열중했다. (객체 그래프 탐색으로 다 하고 싶어했다)
어디까지 결합을 시켜서 → 객체 그래프 탐색으로 접근 가능하게 할지에 대한 기준이 없었다.
아직 비즈니스 자체가 작아서 그렇지, 좀만 더 커지면 서로 얽혀버려서 떼어내기가 보통 일이 아닐 것이다.
의존성에 대해Assocation은 객체간의 결합도가 아주 높아지고, 불필요한 부분까지 객체 그래프 탐색을 통해 접근할 수 있게 하는 문제가 있다.
따라서 의존성 사이클이 생기면 나중에 변경이 어렵다.
서로 생명주기가 너무 다른 컨텍스트 간에는 Id로 간접 참조를 고려해보자.
그리고 분리가능한 것은 분리해보자
양방향 의존성에 대해 양방향 의존성은 사실 당장은 문제 없지만, 강한 결합으로 인해 앞으로의 확장과 분리에 걸림돌이 될 것이다.꽉 맞물린 나무 결합을 상상해보자. 떼어내기가 굉장히 어려울 것이고, 소프트웨어에서는 지양하는 바다.
dovetail joint
개선해보기
의존성 사이클 제거
AS-IS
TO-BE
패키지 의존성이 한 방향으로 흐르도록 리팩터링한다.
DI와 EventListener를 사용했다.
기존 auth 패키지 -> member 패키지에 접근하는 부분은 DI를 사용해 IoC 했다.
member 패키지 -> applegame 패키지에 접근하는 부분은 EventListener를 활용했다.
잠시만요.. EventListener도 IoC 방법 중 하나인 것 같네요?Event-driven programming is often implemented using IoC so that the custom code need only be concerned with the handling of events, while the event loop and dispatch of events/messages is handled by the framework or the runtime environment. In web server application frameworks, dispatch is usually called routing, and handlers may be called endpoints.실제로 IoC 방법중 하나로 Wikipedia에 소개되고 있다.
이제 패키지가 확실하게 분리되고 의존성이 한 방향으로 흐르게 되어, 작은 모듈로 분리할 수 있는 상태가 되었다.
가장 먼저 분리하고픈건 OAuth 부분이다.
결과