2024년 3월 4주차 주간회고

Clean + Layered Architecture

이번 2주 차 과제는 아키텍처 설계가 중점인 과제를 진행했다.

평소 애플리케이션을 구성할 때 아키텍처 설계 없이 무지성으로 Layered Architecture로 설계하여 애플리케이션을 만들었었는데, 이번 과제를 진행하면서 다양한 아키텍처에 대해 배울 수 있었다. (Layered, Clean, Hexagonal, Clean + Layerd)

 

 

이제껏 무지성으로 설계해 왔던 아키텍처를 실제 애플리케이션을 만들 때, 어떻게 아키텍처를 설계할지 고민하며 "이렇게 설계했을 때의 장점이 무엇이지?", "기존에 내가 설계했던 방식은 이러한 문제점이 있었구나" 같은 생각들을 정리하고 몸으로 직접 느낄 수 있었다.

 

가장 크게 배운 부분은 "하위 계층의 변경은 상위 계층으로 전파되지 않아야 한다" 원칙이다.

 

예를 들어 평소 Service 단에서 필요한 Repository를 바로 의존해 사용하고 있었는데(전형적인 Layered Architecture) 이렇게 설계를 하게 되면 Repository를 변경하게 되면 불가피하게 이를 의존하고 있는 service도 수정해야 하는 번거로움이 발생한다. 애플리케이션이 작다면 "뭐 이 정도야" 하고 수정하고 넘길 수 있겠지만 애플리케이션의 크기가 커질수록 이는 매우 큰 비용으로 발생한다는 것을 회사 코드를 리팩터링 하면서 느낀 적이 있다.

 

아무튼 Service에서 바로 Repository를 의존하는 게 아닌 추상화된 Repository 인터페이스를 의존함으로써 service와 repository 간 강한 의존성을 끊어줄 수 있다.

이제 service는 추상화된 repository를 의존하고 있기 때문에 repositorty의 구현체가 변경되더라도 service를 수정할 일은 없다.

즉, 하위 계층의 변경이 상위 계층으로 전파되지 않도록 layer 간 독립적으로 아키텍처를 설계할 수 있다고 볼 수 있다.

 

우리가 흔히 말하는 OCP 원칙이 아주 잘 지켜진 케이스라고 보면 된다.

 

니가 아는 게 아는 게 아니야

이번 주에 팀원 분 한분이 엔티티와 도메인의 차이에 대해 질문을 주셨는데, 설명할 때 나조차 말하면서 무슨 말을 하고 있는 거지? 라는 느낌을 받았다.

Q. "도메인과 엔티티의 차이가 뭔가요?"

A. "도메인과 엔티티의 차이가 뭐냐면요.. 일단 도메인과 엔티티는 다릅니다. 그런데 같아요!"

 

 

아무래도 나는 도메인과 엔티티에 대한 차이를 모르고 있는 것 같아 급하게 다음날 코치님에게 따로 질문을 드려 이 개념에 대해서도 한번 확실하게 정리하고 갈 수 있었다.

 

내가 알고 있는 것 같은 개념도 남에게 설명할 수 있어야 그 개념에 대해 알 수 있다고 말할 수 있을 것 같다는 것을 온몸으로 느낄 수 있었다.

 

Entity와 Domain 용어의 차이에 대해서는 포스팅하기 좋은 주제 같아 빠른 시일 내에 포스팅할 예정이다.

 

이번에는 컴포넌트 중심 설계도 해보고, 모듈 분리도 시도(만) 해보고, 엔티티와 도메인을 다른 개념으로 적용해서 설계도 해보고 평소 해보지 못했던 것들을 많이 시도해 보면서 정말 많은 경험을 할 수 있었던 한 주였다.

 

다음 주는 지금껏 배운 TDD, Architecture를 적용하여 3개의 시나리오중 하나 선택해서 서버 구축 과제인데 진짜 진짜 진짜 TDD 적용해서 서버 구축해 보자..

맨날 머리로는 TDD 해야지 하면서 손은 로직부터 작성하고 있었는데, 이번에는 제발 테스트 부터 작성하자!