Week I Learend

이번 주에 레벨 4를 시작했다.

원래 화요일에 레벨 4 시작인데 이번엔 특이하게 레벨을 시작하면서 지난 레벨의 레벨 말하기를 했다.
그래서 수요일은 재택을 했고, 정식적으로는 목요일부터 시작했다.

이틀밖에 안됐지만 그동안 배운 것들을 기록하고자 한다.

아키텍쳐, 디렉터리 구조

백엔드끼리 정한 과업?은 아래와 같다.

정하게 된 스토리는 대충 이렇다.
현재 패키지 구조를 아래 사진처럼 도메인형으로 가져갔다.

하지만, 음식점을 조회하는 Query성 Service와 Repository가 핵심 비즈니스 로직만 존재해야하는 domain 패키지 내에 위치하게 되었고, 자연스레 클라이언트에 응답을 내려줄 dto들도 domain 아래에 위치하게 되었다.

난 사실 지저분한 조회성 로직이나 쿼리를 깔끔하게 하는 정도로만 생각하고 있었는데, 말랑이 패키지 구조 자체와 아키텍쳐를 변경하자고 제안했다.
처음엔 그렇게까지 해야 할 작업인가 싶었지만, 덕분에 CQS란 키워드에 대해 알게 되었고 이에 설득당해버렸다.

레벨 2까지는 설계가 너무 재밌고 아키텍처에 대해 관심이 많았지만, 프로젝트를 진행하면서는 그 외에 기본적인 것들을 채우기 위해 신경쓰지 않았다.
하지만 이번 일 계기로 아키텍쳐와 디렉터리 구조에 대해 중요성을 인지할 수 있었다.

덕분에 이번에 Command와 Query가 같이 있는 패키지 구조에서 분리하는 작업 또한 경험할 수 있었다.

유연한 서비스는 ?? ??가 만든다.

팀끼리 레벨 4에 구현할 기능들을 정하는 과정에서 이런 저런 아이디어가 나왔다.
그런데 중간에 어떤 기능을 듣자마자, 백엔드 팀원 전원이 흠칫하며 곤란해하는 순간이 있었다.

이유는 바로 위에서 언급한 복잡한 조회 로직때문이었다.

난 이 순간 바로 생각난 플로우가 '현재 코드가 복잡하다 -> 새로운 기능을 추가하거나 변경할 때 굉장히 복잡하겠다는 생각이 가장 먼저 든다 -> 유연하지 못한 서비스가 된다 -> 서비스는 망한다' 이다.

그동안 클린 코드, 클린 아키텍쳐 등등.. 변경에 유연하기 위해 중요한 것들이다!! 라고 세뇌당할 정도로 들었지만, 이렇게까지 몸소 체험한 적은 처음이다.

나에게 요즘은 많은 내용을 학습하는 시즌이라고 생각한다. 그래서 예전만큼 클린 코드와 좋은 구조에 대한 고민을 하지 못하고 있다.
얼른 새로운 많은 것들을 익히고 다시 클린 코드, 클린 아키텍쳐에 대해 공부하고 싶다.