계층형 아키텍처 극복하기
단일 책임 원칙과 의존성 역전 원칙
단일 책임 원칙은 하나의 컴포넌트는 오로지 한 가지 일을 해야하고, 그것을 올바르게 수행해야 한다는 뜻으로 알려져 있습니다. 그런데 단일 책임 원칙의 실제 정의는 “컴포넌트를 변경하는 이유는 오직 하나뿐이어야 한다.” 입니다.
단일 책임 원칙을 좀 더 깊게 이해하기 위해서 단계적으로 들어가보겠습니다. 우선 웹 - 도메인 - 영속성의 구조를 가지는 게층형 아키텍처에서 서비스 규모가 매우 커진 상황을 가정합니다. 도메인이라는 거대한 층은 엄청나게 많은 비즈니스 로직들을 담고 있습니다. 도메인이라는 하나의 계층에서 각자의 역할을 하는 컴포넌트를 정의하고 컴포넌트 A에서 컴포넌트 B,C,D 를 사용하는 것은 당연합니다. A에서 B,C,D를 사용하는 것만으로 강한 의존성이 생겼다고는 말하지 않습니다. 하지만 A의 역할에 대한 정의가 불문명한 상태로 A가 B부터 Z까지 너무 많은 컴포넌트를 사용하도록 하면 곤란해집니다. 어느정도가 되면 A를 A1과 A2로 나누어야겠죠. 여기까지의 과정들이 “하나의 계층 안에서의 단일 책임 원칙”이라고 이해됩니다. “A는 혼자 존재해야하며 B,C,D를 사용하면 안된다”가 아니라 “A의 역할이 너무 커지기 전에 A1과 A2로 나누어야한다.”입니다.
도메인과 영속성이라는 두 계층 사이에 단일 책임 원칙을 적용해보겠습니다. 여기서 의존성 역전 원칙이 등장합니다. 도메인 계층은 영속성 계층을 사용하기 때문에 영속성 계층에 변화가 있을 때면 도메인 계층에 변화가 발생합니다. 하지만 이러한 의존성의 방향을 반대로 뒤집을 수 있습니다. 도메인 계층에서 영속성 계층이 사용해야하는 interface를 가지고 있고, 영속성 계층은 이에 따르면 됩니다. 이렇게 되면 도메인 계층은 영속성 계층이 변경되었다는 이유로 변경되어야 하는 상황이 발생하지 않습니다. 오히려 인터페이스의 변경이 생기면 도메인 계층이 영속성 계층에게 “이렇게 동작하게 변해줘.”라고 요구하는 상황이됩니다.
단일 책임 원칙과 의존성 역전 원칙은 하나의 계층 안에서도 동작할 수 있고, 서로 다른 계층 사이에서 동작할 수도 있습니다. 이렇게 적용되나 저렇게 적용되나 목적은 ‘변경되어야 하는 이유’를 줄이는 것입니다.
'DEV > Architecture' 카테고리의 다른 글
헥사고날 아키텍처 시리즈 6. 영속성 계층 (0) | 2024.03.16 |
---|---|
헥사고날 아키텍처 시리즈 5. 애플리케이션 계층 (0) | 2024.03.16 |
헥사고날 아키텍처 시리즈 4. 패키지 구조 (0) | 2024.03.15 |
헥사고날 아키텍처 시리즈 3. 헥사고날 아키텍처 시작하기 (0) | 2024.03.14 |
헥사고날 아키텍처 시리즈 1. 계층형 아키텍처의 문제점 (0) | 2024.03.14 |