클린 아키텍처

김재연·6일 전

헥사고날 아키텍처 클린 아키텍처

아키텍처의 중요성

아키텍처란 ? 소프트웨어가 제공하는 가치인 기능과 구조 중 구조에 포함되는 것입니다.

클린 코드, 클린 아키텍처 글을 쓴 저자는 기능과 구조 중 구조가 더 중요하다고 판단합니다.

보통 우리가 접하는 코드는 굉장히 복잡하다고 판단하는 경우가 많습니다. 바로 아래와 같은 경우이죠.

이렇게 어지러운 방에다가 새로운 가구를 들여놓는다면, 굉장히 어려울 것입니다.

하지만 만일 방이 아래와 같은 상태이면 어떨까요?

이와 같이 상태를 유지하게 되면 새로운 가구를 놓을 때에도 굉장히 편하지 않을까요? 하지만, 이는 너무 이상에 가깝습니다.

그렇기 때문에 우리는 그의 중간인 아래와 같은 방을 선호해야 합니다.

좋은 아키텍처가 중요한 이유는 유지보수에 있습니다.

코드 읽기, 이해하기, 수정/추가가 등등이 수월하게 이루어져야하죠.

이러한 유지보수에 투입되는 인력을 최소화 할 수 있게끔 도와주는 것이 클린 아키텍쳐입니다.

좋은 아키텍처와 좋지 않은 아키텍처는 위와 같은 특징이 있습니다.

좋은 아키텍처를 만드는 방법을 쉽게 정의하면 위와 같습니다.

응집성을 높이고 결합도를 낮춰야하고, 그러기 위해 SOLID 원칙과 같은 패러다임을 준수해야합니다.

코드를 통해 기능을 구현해 본 경험이 있다면 3-layered 아키텍처와 같은 보편적인 아키텍처를 잘 아실 것입니다.

이런 패턴은 좋은 구조를 비교적 쉽게 유지할 수 있도록 도와줍니다. 이러한 구조 패턴을 준수하는 것만으로도 클린 아키텍처를 구축에 도움을 줍니다.

하지만 Layered 아키텍처는 위와 같은 단점이 존재합니다.

도메인과 인프라의 구분이 명확하지 않지만, 구조가 단순하기에 굉장히 빠르게 개발이 가능하다는 장점이 존재하죠.

클린 아키텍처는 어떨까요? 도메인을 중심으로 아키텍처를 구축하기에, 규칙이 단순하고, 도메인이 인프라에 의존되지 않습니다.

하지만, 계층형 아키텍처보다는 복잡하기에, 간단한 기능을 구현하더라도 리소스가 많이 들어간다는 단점이 있습니다.

중요도마다 계층을 나눈다는 것이 레이어드 아키텍처와 비슷합니다. 하지만, 모든 의존성의 방향이 도메인 쪽으로 향하는 것이 클린 아키텍처의 핵심입니다.

클린아키텍처와 헥사고날 아키텍처는 되게 비슷합니다.

그래서 보통 둘이 동일하다고 봐도 괜찮고, 헥사고날 아키텍처를 클린 아키텍처라고 칭하여 부르는 경우도 많이 존재합니다.

다음과 같이 도메인을 바라보고 있기 때문에, 조금 더 도메인 기반 프로그래밍을 진행할 수 있습니다.

앞서 언급하였지만, 도메인이 다른 사항들에 대해 의존하지 않기 때문입니다.

아키텍처가 애매하다라고 느껴진다면, 위와 같은 기준을 적용해볼 수 있습니다.

이런 부분으로 미루어 보았을 때, 헥사고날 아키텍처는 굉장히 좋은 아키텍처라는 것을 알 수 있습니다.

이럴 땐 쓰지 마세요

소규모의 프로젝트를 진행할 때, 프로젝트 개발자 모두가 클린 아키텍처를 이해하고 있지 않을 때, 모두가 사용하기로 합의하지 않았을 때 사용하게 되면 클린 아키텍처의 장점을 원활하게 느낄 수 없을 것입니다.

의존성을 자르기 위해 파일이 늘어나고, 패키지 수도 당연히 늘어납니다.

하지만, 꼭 필요한 부분이죠.

infra 관련 Entity, Domain Entity (POJO) 를 꼭 분리해야 할까요?

빠른 개발을 위해서는 분리하지 않을 수도 있다는 생각이 듭니다.

하지만, 이를 완전하게 분리한다면 영속 관련 기술이 변화되었을 때, 유연하게 대처가 가능하고, 조금 더 POJO 스러운 개발을 잘 할 수 있게 됩니다. 개인적으로 이가 굉장히 큰 장점이라고 생각합니다.

하나로 사용하게 되었을 때, 위와 같은 단점과 장점이 존재할 수 있습니다.

Jpa Repository는 어디에다가 두어야 할까요?

헥사고날 아키텍처는 도메인과 외부 환경을 분리하기 위해 UseCase 개념(interface)을 사용합니다. 이는 절대로 외부 환경에 의해 변경이 되어서는 안됩니다.

그렇기 때문에 Jpa Repository는 UseCase를 구현하는 쪽에 두어야 합니다. 이렇게 되면 DIP(의존성 역전)를 통해 구현 기술을 바꾸기가 쉬워집니다.

항상 고민되는 지점이 있습니다. Service 가 다른 Service를 필요로 한다면 어떻게 구현해야 할까요?

UseCase를 호출하는 것도 좋지만, 완전이 분리하고 싶다면 Port를 통해 노출하는 것이 더 깔끔합니다.

인터페이스로 구현하지 않는다고 해도 의존성의 방향이 바뀐다거나 그렇지는 않지만, Controller가 Service의 경계를 확실하게 그어줘, 사고의 경계를 그어줍니다.

정리하면 다음과 같습니다.

좋은 아키텍처 - 클린 아키텍처의 원칙을 따른 것
클린 아키텍처 - 계층의 중요도를 나누고 더 중요한 계층쪽으로 의존성이 향해야한다.

클린 아키텍처는 애매하지만 규칙이 단순하기에, 본인만의 기준을 가지고 코드를 짜면 유지보수하기 좋은 코드를 만들어낼 수 있을 것입니다.

김재연

끊임없이 '성장'하는 개발자 김재연입니다.

이전 포스트

클린 아키텍처

아키텍처의 중요성

이럴 땐 쓰지 마세요

객체 지향이 무엇일까 다시 돌아보자

0개의 댓글