본 시리즈는 "만들면서 배우는 클린 아키텍처"(톰 홈버그 저)의 책으로 공부하며 정리한 내용을 담고있습니다.

단일 책임 원칙(Single Responsibility Principle, SRP)

단일 책임 원칙의 일반적인 해석은 다음과 같다.

하나의 컴포넌트는 오로지 한 가지 일만 해야 하고, 그것을 올바르게 수행해야 한다.

하지만, 단일 책임 원칙의 실제 정의는 다음과 같다.

컴포넌트를 변경하는 이유는 오직 하나뿐이어야 한다.

책임은 '오로지 한 가지 일만 하는 것' 보다는 '변경할 이유'로 해석해야 한다.

이 말인 즉, 만약 컴포넌트를 변경할 이유가 한 가지라면 우리가 어떤 다른 이유로 소프트웨어를 변경하더라도 이 컴포넌트에 대해서는 전혀 신경 쓸 필요가 없다.
소프트웨어가 변경되더라도 여전히 우리가 기대한 대로 동작할 것이기 때문이다.

많은 코드는 단일 책임 원칙을 위반하기 때문에 시간이 갈수록 변경하기가 더 어려워지고 변경 비용도 증가한다.
위에서 말한 변경할 이유가 많이 쌓인 코드는 한 컴포넌트를 바꾸는 것이 다른 컴포넌트가 실패하는 원인으로 작용할 수 있다.

의존성 역전 원칙 (Dependency Inversion Principle, DIP)

계층형 아키텍처에서 계층 간 의존성은 항상 다음 계층인 아래 방향을 가리킨다.
영속성 계층에 대한 도메인 계층의 의존성 떄문에 영속성 계층을 변경할 때마다 잠재적으로 도메인 계층도 변경해야한다.
애플리케이션에서 가장 중요한 코드인 도메인 코드가 영속성 코드가 바뀐다고 해서 바뀌고 싶지 않다면 어떻게 해야할까?

의존성 역전 원칙 (Dependency Inversion Principle, DIP) :
코드상의 어떤 의존성이든 그 방향을 바꿀 수 (역전시킬 수) 있다.

👆🏻도메인 계층에 영속성 계층의 엔티티와 리포지토리가 상호작용하는 서비스에서
도메인 계층에 인터페이스 도입함으로서 의존성 역전이 가능해졌다.
그 덕분에 영속성 계층이 도메인 계층에 의존하게 되었다.

엔티티는 도메인 객체를 표현하고 도메인 코드는 엔티티들의 상태를 변경하는 일을 중심으로 하므로, 엔티티를 도메인 계층으로 올림.
영속성 계층의 리포지토리가 도메인 계층에 있는 엔티티에 의존하기 때문에 두 계층 사이에 순환의존성이 생긴다.
도메인 계층에 리포지토리에 대한 인터페이스, 실제 리포지토리는 영속성 계층에서 구현.

클린 아키텍처

클린아키텍처에서는

• 설계가 비즈니스 규칙의 테스트를 용이하게 함.
• 비즈니스 규칙은 프레임워크, 데이터베이스, UI기술, 그 밖의 외부 애플리케이션이나 인터페이스로부터 독립적일 수 있다.

'도메인 코드가 바깥으로 향하는 어떤 의존성도 없어야 함'을 의미.
대신 모든 의존성이 도메인 코드를 향하고있다.

도메인 코드에서 어떤 영속성 프레임워크나 UI프레임 워크가 사용되는지 알 수 없기 때문에 비즈니스 규칙에 집중할 수 있다. > 도메인 코드를 자유롭게 모델링 가능

도메인 계층이 영속성이나 UI계층과 같은 외부계층에서 철저히 분리되어야 하므로 애플리케이션의 엔티티에 대한 모델을 각 계층에서 유지보수 해야한다.

헥사고날 아키텍처

육각형 안에는 도메인 엔티티와 이와 상호작용하는 유스케이스가 있다.
육각형에서 외부로 향하는 의존성이 없으므로 의존성 규칙이 그대로 적용된다.
대신 모든 의존성은 코어를 향한다.

왼쪽 어댑터들은 애플리케이션을 주도하는 어댑터, 오른쪽 어댑터들은 애플리케이션에 의해 주도되는 어댑터들이다.

애플리케이션 코어와 어댑터들 간의 통신이 가능하려면 애플리케이션 코어가 각각의 포트를 제공해야한다.

도메인의 비즈니스 로직을 외부 라이브러리 및 툴로부터 분리 할 때 포트와 어댑터라고 부르는 인터페이스를 사용하기 때문에 포트&어댑터 아키텍처라고도 부른다.

도메인 비즈니스 로직이 외부요소에 의존하지 않게 만들고, 프레젠테이션 계층(controller)과 데이터 소스 계층(persistence) 같은 외부 요소들이 도메인 계층에 의존하도록 한다.
→ 외부와의 접촉을 인터페이스로 추상화하여 비즈니스 로직 안에 외부 코드나 로직의 주입을 막는 것, 외부 라이브러리 및 툴로부터 분리시키는 것이 아키텍처의 핵심