[항해플러스 7기 백엔드] 2주차 회고 (1) - 클린 아키텍처

클린 아키텍처

2주차 과제의 핵심 키워드는 아키텍처 였다.

 

클린 코드, 클린 아키텍처, 클린 코더의 저자, Robert C Martin은 대부분의 아키텍처는 세부적인 차이는 있어도 공통적인 목표는 계층을 분리하여 관심사의 분리하는 것이라고 말하는데, 이런 아키텍처가 동작하기 위해서는 의존성 규칙을 지켜야 한다고 한다.

의존성 규칙이란?

모든 소스코드 의존성은 반드시 외부에서 내부로, 저수준에서 고수준 정책을 향해야 한다. 

 

레이어드 아키텍처

아직까지 많은 회사에서 사용하는 아키텍처 구조는 레이어드 아키텍처 일 것이다.

하지만 레이어드 아키텍처에서는 고수준 정책(Service)이 저수준 정책(DB의 구현체)을 직접 참조하게 되고 이는 위에서 언급한 의존성 규칙을 위반한다. 우리는 이것을 DIP(의존성 역전의 원칙, Dependency Inversion Principle)을 통해 해결할 수 있다.

 

클린-레이어드 아키텍처

이번 주차 과제에서는 레이어드 아키텍처의 구조에 DIP를 적용한 클린-레이어드 아키텍처 구조로 진행하였다.

 

 

내가 잡은 아키텍처 구조는 다음과 같다.

 

domain/ : 도메인 클래스와 관련 서비스 로직, Repository(interface)

infrastructure/ : DB 관련 로직(저장, 조회, 수정, 삭제 등), domain 패키지 내 Repository 인터페이스를 구현한 구현체 클래스

interfaces/ : Controller 클래스와 요청, 응답 객체 클래스

(application/) : 도메인 패키지의 서비스를 조합해서 사용하는 Facade 클래스

 

이번 과제에서는 Lecture 도메인 하나에서 모든 요구사항 구현이 가능하여 Facade 클래스를 따로 작성하지는 않았다. 

 

 

 

 

 

 

 

 

 

 

 

 

---

레이어드 아키텍처 구조로만 코드를 작성해보다가 새로운 아키텍처의 개념을 이해하려고 하니 처음에는 어려움이 있었다.

하지만 코치님들의 멘토링을 열심히 청강하고, 과제를 진행하다보니 왜 이런 아키텍처 구조를 사용해야 하는지를 이해할 수 있었다!

 

클린 아키텍처책을 읽었던 당시에는 잘 이해되지 않아 읽고 있는데도 '글은 글이고....' 이런 느낌으로 글자만 읽는 느낌이었다.

지금 다시 읽게 되면 굉장히 재밌게 읽을 수 있을 것 같다는 생각이 든다. (틈틈히... 시간을 내어 다시 읽어봐야겠다. 🥲)

책의 내용을 다시 떠올려보자면... '우리는 유지보수가 용이한 아키텍처를 갖추어야 한다.'

이러한 아키텍처 구조를 갖추게 되면, DB 변경 등에 대한 확장이 용이하고 테스트 코드 작성하기에도 좋은 구조라는 것을 느꼈다.

 

아직 이 구조에 완벽하게 익숙해지지 않았지만, 의존성 규칙을 항상 상기하면서 개발을 해야겠다..