클린 아키텍처 적용

이전에 CQRS 패턴으로 Command와 Query 로직을 분리해 보았습니다.

프로젝트를 더 확장하기 전에 파일구조를 더 효율적으로 만들고 유지보수에 유리한 아키텍처 구조의 프로젝트로 만들고 싶었습니다.

 

'클린 아키텍처'라는 좋은 아키텍처를 적용한 프로젝트를 만들어서 아키텍처 설계를 하면 현업에서도 대규모의 애플리케이션을 효율적으로 관리 할 수 있겠다는 생각이 들었습니다.

 

그럼 '클린 아키텍처'는 무엇이고 어떻게 구현하고 또 현재 프로젝트에서 어떻게 구현하게 되었는지 알아보겠습니다..

 

클린 아키텍처

클린 아키텍처는 <클린 코드>의 저자 로버트 C.마틴이 제안한 아키텍처입니다. 클린 아키텍처는 전혀 새로운 아키텍처는 아니고 양파 아키텍처라고 불리던 아키텍처에서 발전한 것입니다. 소프트웨어를 여러 동심원 레이어로 나누고 각 레이어에 있는 컴포넌트는 안쪽 원에 있는 컴포넌트에만 의존성을 가지도록 합니다. 따라서 안쪽 원에 존재하는 컴포넌트는 바깥원에 독립적입니다.

 

출처: https://hwannny.tistory.com/41

 

클린 아키텍처는 위의 그림과 같이 레이어 4개로 분류합니다.

가장 바깥쪽 레이어부터 아래의 구조를 가집니다.

1. 인프라스트럭처

2. 인터페이스

3. 애플리케이션

4. 도메인

 

인프라 스트럭처 레이어: 우리가 만드는 애플리케이션에 필요는 하지만 외부에서 가져다 쓰는 컴포넌트를 작성합니다. 예를 들어 데이터베이스, 이메일 전송, 다른 서비스와의 통신 프로토콜 구현체 등 외부에서 들어오는 요청은 어떤 형식이여야 하고 나가는 데이터는 어떠한지를 제공합니다. 마찬가지로 게이트웨이나 프레젠터와 같은 컴포넌트도 외부와의 인터페이스를 담당하고 있습니다.

 

인터페이스 레이어: 우리 서비스가 제공하는 인터페이스가 구현되는 레이어, 컨트롤러는 외부에서 들어오는 요청은 어떤 형식이어야 하고 나가는 데이터는 어떠한지를 제공합니다.  마찬가지로 게이트웨이나 프레젠터와 같은 컴포넌트도 외부와의 인터페이스를 담당하고 있습니다.

 

애플리케이션 레이어: 애플리케이션의 비즈니스 로직이 구현되는 레이어입니다. 서비스들이 여기에 존재합니다. 유저 서비스의 예를들면 회원가입, 회원정보 조회 등의 로직을 구현합니다.

 

도메인 레이어: 애플리케이션의 핵심 도메인을 구현하는 레이어입니다. 도메인 레이어는 다른 레이어에 의존하지 않습니다. 따라서 애플리케이션이 가져야 하는 핵심 요소만 가집니다. 만약 도메인  레이어의 컴포넌트가 변경된다면 이를 이용하는 다른 모든 레이어를 수정해야 하므로 신중하게 작성해야 합니다.

 

클린 아키텍처(명확한 아키텍처 구조)를 사용하지 않을 시 문제점

높은 결합

 

- 명확한 아키텍처 구조가 없으면 시스템 구성 요소가 긴밀하게 결합되는 문제가 발생합니다. 이는 시스템의 한 부분을 변경하면 다른 부분에 의도하지 않고 예측할 수 없는 영향을 미칠 수 있음을 의미합니다. 이로 인해 코드베이스를 유지 관리하고 업데이트하기가 어려워집니다.

 

테스트의 어려움

 

- 클린 아키텍처는 비즈니스 로직에 대한 단위 테스트 사용을 촉진하여 각 구성 요소가 격리되어 예상대로 작동하는지 더 쉽게 확인할 수 있습니다. 클린 아키텍처가 없으면 테스트가 더 어려워지고 시스템의 특정 부분을 격리하고 테스트하기가 어려울 수 있습니다.