단일 책임 원칙
단일 책임 원칙은 일반적으로 "하나의 컴포넌트는 오로지 한 가지 일만 해야 하고, 그것을 올바르게 수행해야 한다." 해석되지만 이는 실제 의도가 아니다.
단일 책임 원칙
컴포넌트를 변경하는 이유는 오직 하나뿐이어야 한다.
컴포넌트를 변경할 이유가 오로지 한 가지라면 컴포넌트는 딱 한 가지 일만 하게 된다.
어떤 다른 이유로 소프트웨어를 변경하더라도 이 컴포넌트에 대해서는 전혀 신경 쓸 필요가 없다.
소프트웨어가 변경되더라도 여전히 우리가 기대한 대로 동작할 것이기 때문이다.
의존성 역전 원칙
계층형 아키텍처에서 계층 간 의존성은 항상 다음 계층인 아래 방향을 가리킨다.
단일 책임 원칙을 고수준에서 적용할 때 상위 계층들이 하위 계층들에 비해 변경할 이유가 더 많다는 것을 알 수 있다.
의존성 역전 원칙
코드상의 어떤 의존성이든 그 방향을 바꿀 수(역전시킬 수) 있다.
클린 아키텍처
로버트 C. 마틴은 클린 아키텍처에서는 설계가 비즈니스 규칙의 테스트를 용이하게 하고, 비즈니스 규칙은 프레임워크, 데이터베이스, UI 기술, 그 밖의 외부 애플리케이션이나 인터페이스로부터 독립적일 수 있다고 이야기했다.
이는 도메인 코드가 바깥으로 향하는 어떤 의존성도 없어야 함을 의미한다.
대신 의존성 역전 원칙의 도움으로 모든 의존성이 도메인 코드를 향하고 있다.
이 아키텍처에서 가장 중요한 규칙은 의존성 규칙으로 계층 간의 모든 의존성이 안쪽으로 향해야 한다는 것이다.
코어에는 주변 유스케이스에서 접근하는 도메인 엔티티들이 있다.
유스케이스는 서비스라고 불렀던 것으로 단일 책임을 갖기 위해 조금 더 세분화돼 있다.
이를 통해 넓은 서비스 문제를 피할 수 있다.
코어 주변으로 비즈니스 규칙을 지원하는 애플리케이션의 다른 모든 컴포넌트들을 확인할 수 있다.
여기서 '지원'은 영속성을 제공하거나 UI를 제공하는 것 등을 의미한다.
또한 바깥쪽 계층들은 다른 서드파티 컴포넌트에 어댑터를 제공할 수 있다.
도메인 코드에서는 어떤 영속성 프레임워크나 UI 프레임워크가 사용되는지 알 수 없기 때문에 특정 프레임워크에 특화된 코드를 가질 수 없고 비즈니스 규칙에 집중할 수 있다.
그래서 도메인 코드를 자유롭게 모델링 할 수 있다.
클린 아키텍처에는 도메인 계층이 외부 계층과 철저하게 분리돼야 하므로 애플리케이션의 엔티티에 대한 모델을 각 계층에서 유지보수해야 한다.
헥사고날 아키텍처
헥사고날 아키텍처는 클린 아키텍처에서 일반적인 용어로 설명한 것과 동일한 원칙을 적용한다.
육각형 안에는 도메인 엔티티와 이와 상호작용하는 유스케이스가 있다.
육각형에서 외부로 향하는 의존성이 없기 때문에 클린 아키텍처에서 제시한 의존성 규칙이 그대로 적용된다.
대신 모든 의존성은 코어를 향한다.
육각형 바깥에는 애플리케이션과 상호작용하는 다양한 어댑터들이 있다.
애플리케이션 코어와 어댑터들 간의 통신이 가능하려면 애플리케이션 코어가 각각의 포트를 제공해야 한다.
주도하는 어댑터(driving adapter)에게는 그러한 포트가 코어에 있는 유스케이스 클래스들에 의해 구현되고 호출되는 인터페이스가 될 것이고 주도되는 어댑터(driven adapter)에게는 그러한 포트가 어댑터에 의해 구현되고 코어에 의해 호출되는 인터페이스가 될 것이다.
이러한 핵심 개념으로 인해 헥사고날 아키텍처를 port and adapters 아키텍처라고도 부른다.
가장 바깥쪽에 있는 계층은 애플리케이션과 다른 시스템 간의 번역을 담당하는 어댑터로 구성돼 있다.
다음으로 포트와 유스케이스 구현체를 결합해서 애플리케이션 계층을 구성할 수 있는데 이 두가지가 애플리케이션의 인터페이스를 정의하기 때문이다.
마지막 계층에는 도메인 엔티티가 위치한다.
어떻게 도움이 될까?
의존성을 역전시켜 도메인 코드가 다른 바깥쪽 코드에 의존하지 않게 함으로써 영속성과 UI에 특화된 모든 문제로부터 도메인 로직의 결합을 제거하고 코드를 변경할 이유의 수를 줄일 수 있다.
그리고 변경할 이유가 적을수록 유지보수성은 더 좋아진다.
도메인 코드는 비즈니스 문제에 딱 맞도록 자유롭게 모델링될 수 있고 영속성 코드와 UI 코드도 영속성 문제에 맞게 자유롭게 모델링될 수 있다.
