[모각코] 2022 동계 모각코 4회차 결과

 

 

 

 

instanceOf 분리하기

알림은 여러 종류가 있습니다.

여러 종류의 이벤트를 통해 알림이 각각 생성되며, 알림이 가지고 있어야 할 정보들이 각기 다른 상황이었습니다.

즉 여러 종류의 이벤트 - 여러 종류의 알림 Entity 가 대응되는 상황이었으며
Entity별로 DTO와 Response가 다르게 존재하는 상황이었습니다.

처음에는 알림을 생성하는 이벤트를 추상 클래스로 정의하여 Common 패키지에 위치시켰습니다.

이후 각각의 도메인에서는 해당 이벤트를 상속받아 구현하였고, EventHandler를 정의하여 이벤트를 받으면 대응되는 알림을 생성하여 저장하도록 구현하였습니다.

 

이때 여러 종류의 알림 엔티티는 Notification 패키지에 위치하고 있었고, 다른 도메인에서는 Notification을 모르게 하기 위해 Notifiaction 패키지에서 이벤트에 대응되는 알림을 instanceof를 통해 다음과 같이 구분하여 변환하였습니다.

 

 

이때 Entity는 DTO를 모르도록 구현하고 싶었기에
(DTO는 Application Layer에 존재하므로 domain 계층의 Entity가 이를 알게된다면 domain -> application으로의 의존성이 생기기 때문입니다.),
Entity -> DTO를 변환하는 과정에서도 이와 같이 instanceof를 사용하였습니다.

 

 

마찬가지로 DTO 역시 Presentation 계층의 Response를 모르게 하고 싶었기에 instanceof를 통해 구현하였습니다.

 

 

그러나 instanceof의 를 샤용하는 것이 좋지 않다 판단하여, 다음과 같이 수정하였습니다.

1. 우선 Event -> Entity 매핑에서는 전략 패턴을 사용하여 구현하였습니다. 각 전략은 이벤트를 대응되는 알림으로 변환하는 코드만 작성하면 됩니다.
2. instanceOf보다는 Entity가 DTO를 알게 하는 편이 나을 것 같았습니다.(복잡도가 훨씬 낮으며, 또한 알림의 종류가 많아질 경우 훨씬 실수할 위험도 줄어들 것이라 생각하였습니다.)
   따라서 Noticiation이라는 추상 클래스에 toDto()라는 추상 메서드를 만들어 각 클래스별로 대응되는 DTO를 반환하게끔 구현합니다.
3. 마찬가지로 Application Layer의 DTO 에서 Presentation Layer의 Response로 변환하는 과정 역시 DTO.toResponse()라는 추상 메서드를 통해
   구현하였습니다.

위 과정을 통해 결국 Notification에서는 Domain -> Application으로의 의존성과, Application -> Presentation으로의 의존성이 생겼으나,
instanceOf를 사용할 때 보다 코드도 깔끔해 졌으며, 무엇보다 이후 새로운 알림의 종류가 추가되었을 때 이를 위한 코드의 변경이 불필요해지며, 실수할 위험성도 줄어들었음을 느끼고,
이러한 장점이 더 크다 생각해 변경된 구조를 선택하였습니다.