🤩 클린 아키텍처

개요

Robert C. Martin의 Clean Architecture를 읽고, 나름의 이해를 위한 노력과 실제 프로젝트에는 어떻게 적용할 것인지에 대한 고민에 대해 포스팅하려 한다.

(정리와 별개로 개인적인 생각이 들어있어 틀린 부분이 있을 수 있습니다.)
(다른 점에 대해서는 의견을 공유해보고 싶습니다!!)

The Clean Architecture 포스트

클린 아키텍처를 사용하는 이유

필요한 부분 (Infra)만 바꿔도 프로젝트 상에 문제가 안된다.

• 소스 코드 안정성 ↑
• 코드 가독성 ↑
• 유지 보수성 ↑

다만, 프로젝트가 급한 상황이라면 천천히 설계를 해나가기 어렵기 때문에 사실 잘 지키기 어렵다.

내용

💡 아키텍처의 제약 조건

포스트에서는 대부분의 아키텍처(Hexagonal, Onion 등…)는 세부사항(비즈니스 로직)은 달라도 공통의 목표는 계층을 분리하여 관심사를 분리하는 것이라고 한다.

위 이미지에서 바깥쪽 원은 메커니즘을, 내부 원은 정책을 의미한다.
바깥-> 안으로 갈수록 고수준의 소프트웨어가 된다.

---

이러한 아키텍처들의 제약조건은 다음으로 정리할 수 있다.

1. 프레임워크에 무관하다.
   • 다양한 프레임워크를 도구로 사용할 수 있어야 한다.
2. 비즈니스 규칙은 UI, DB등 외부요소 없이 테스트 가능해야 한다.
3. UI와 무관해야 한다.
4. DB에 독립적이어야 한다.(Mysql, Oracle…)
5. 비즈니스 로직은 외부 요소와 무관하게 동작해야 한다.

---

이러한 아키텍처가 동작하기 위해서는 (== 관심사를 분리하기 위해서는) 의존성 규칙 을 따라야 한다.

💡 의존성 규칙

의존성 규칙은 모든 소스코드 의존성은 외부 -> 내부 즉, 고수준의 정책을 향해야한다는 것이다.

고수준 : 추상화된 개념

• 데이터를 저장한다.
• 총 근무 시간을 구한다.

저수준 : 세부화된 개념

• mysql에 데이터를 저장한다.
• A사용자의 근무시간을 다 더한다.

---

위의 그림에서 Domain Layer는 비즈니스 로직이 존재하는 영역이다. (계산기는 계산을, 쇼핑몰은 물건의 판매를)

비즈니스의 본질은 쉽게 바뀌지 않으므로 잘 변하지 않는 영역이다.

Infra Layer는 UI, Framework 등이 존재하는 영역이다.
Infra는 자주 바뀌어도 내부 로직은 바뀌지 않는다. (계산 버튼의 색은 바뀌어도 계산기의 계산이 바뀌지 않는다.)
고수준 정책인 Domain은 저수준 정책인 Infra에 대해 아무것도 몰라도 된다.
이렇게 Layer를 구분하여 Infrastructure를 쉽게 변경할 수 있다.

---

Martin의 아키텍처는 4개의 레이어로 구성되어있다.

Entities

전사적 비즈니스 규칙을 담는다.
이는 대규모 프로젝트 내의 다양한 애플리케이션에서 사용될 . 수있다.(애플리케이션에 종속X)

게임으로 치면 몬스터, 아이템 등의 상세 정보 출입통제로 치면 단말기, 유저, 문의 상세 정보 업무 보고 서비스로 치면 업무 보고서

(바뀌지 않는 부분이라 하지만, 사실 내부 사정에 의해 많이 바뀐다…😭)

Use Cases

애플리케이션 별 비즈니스 규칙을 담는다.
서비스를 사용하는 사용자가 애플리케이션을 통해 하고자 하는 것을 의미한다.

게임

• 몬스터를 사냥한다.
• 아이템을 장착한다.

출입통제

• 단말기에 인증한다.
• 단말기를 제어하여 문을 연다.

업무 보고 서비스

• 일일 업무보고를 등록한다.
• 업무 보고를 조회한다.
• 주간 보고를 생성한다.

Interface Adapter

어댑터 계층은 Infra 측에서 사용하기 편하도록 Use Case 혹은 Entities의 데이터를 변환하는 계층이다.
보통 MVC, MVVM의 아키텍처를 포함하는 영역으로 Controller, Presenter 등이 속한다.

Framework && Driver

Infra 계층이라고도 불린다.
DB, Framework 를 포함한다. 보통 내부에 비해 변화가 잦다.

---

💡 의존성 규칙을 지키는 방법

What data crosses the boundaries

경계간의 데이터를 전달할 때 무엇을 전달해야하는가에 대한 이야기다.
의존성을 지키기 위해서는 데이터 구조를 최대한 단순하게 유지하여 각 시스템이 독립적으로 변화할 수 있도록 해야한다.

Crossing boundaries

실제 시스템의 흐름은 사용자의 요청 -> 응답이다.
이 흐름은 원에서 외부 -> 내부 -> 외부인데, 이는 아키텍처의 의존성 규칙에 위배된다.
이 부분이 많이 헷갈리는 부분이었다.
아키텍처의 동심원에서는 repository가 더 바깥부분이지만, 실제 흐름에서는 usecase가 더 바깥부분인것처럼 보이기때문이다.
따라서, usecase가 repository를 호출하는건 의존성 규칙에 위배되고 이를 DIP를 통해서 해결해야한다는 이야기다.

👉 Conclusion

소프트웨어의 일생 주기에서 가장 비용이 많이드는 주기는 유지보수가 이루어지는 단계이다. 잘 구조화되고 추상화된 소프트웨어 시스템은 유지보수 하기 쉽다. 이는 사용자의 요구사항을 받아들이기 쉬워 새로운 가치를 만들어내기 쉽다는 의미다.

클린 아키텍처는 이러한 목표를 이루기 위해 널리 퍼진 하나의 방법론이다. 클린 아키텍처에서 제시하는 모습을 시작으로 좋은 소프트웨어 아키텍처를 어떻게하면 구성할 수 있을지는 계속된 숙제로 가지고 가야할 것 같다.