본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.
패스트캠퍼스의 '9개 도메인 프로젝트로 끝내는 백엔드 웹 개발 (Java/Spring) 초격차 패키지 Online' 강의 수강 4일차!
오늘은 클린 아키텍처의 개념에 대해 학습하고 커뮤니티 피트 서비스의 아키텍처를 설계하는 작업을 진행하였다.
클린 아키텍처
- '비용'은 소프트웨어 아키텍트에 있어서 중요한 포인트 중 하나인데, 클린 아키텍처는 선택지를 넓힘으로써 유연하게 대응할 수 있게 만들고, 이러한 점은 비용을 절감할 수 있다.
클린 아키텍처라는 것에 대해 자주 들어보긴 했지만 제대로 알아보고 코드에 적용시켜본 경험은 많지 않기 때문에 더 집중하여 듣게 되었다 ㅎㅎ
컴포넌트란 시스템의 구성 요소로 배포할 수 있는 가장 작은 단위를 뜻한다. (java의 경우 jar 파일)
이러한 컴포넌트에는 크게 두 가지 레벨이 있는데, 먼저 저수준 컴포넌트는 비즈니스 로직보다 유저와 외부에 가까운 컴포넌트이다. Controller 레이어와 Repository 레이어가 해당된다. 다른 하나는 고수준 컴포넌트로, 비즈니스 로직을 포함하는 컴포넌트를 말한다. Service 레이어와 Domain 레이어가 해당된다.
객체지향 프로그래밍에서 빠지지 않고 언급되는 개념인 '의존성'
저수준 컴포넌트는 쉽게 변경되기 때문에 고수준 컴포넌트는 저수준 컴포넌트를 의존해서는 안된다.
예를 들어 커뮤니티 피드 서비스의 본질인 글을 쓸 수 있다(비즈니스 로직)는 잘 변경이 되지 않지만, 유저가 늘어남에 따라 db는 캐싱을 도입하거나 테이블 형태가 변경되는 등의 저수준 컴포넌트는 쉽게 변경이 가능해야 한다.
그렇다면, 자주 사용하는 레이어 아키텍처(Controller -> Service - Domain -> Repository)는 고수준인 Service가 저수준인 Repository를 의존하는 것인데 이건 어떻게 해결할 수 있는지에 대한 의문이 생겼다.
이 경우, 인터페이스를 이용하여 의존성을 역전시켜 DIP를 달성하면 된다.
개발을 하며 꼭 적용시키고 싶지만 어떻게 해야 할지 방법을 몰랐던 클린 아키텍처에 대해 알아보고 직접 코드에 적용시켜볼 수 있어서 좋았다.