Clean Architecture 정리 - 5부 27장 크고 작은 모든 서비스들

시스템의 아키텍처는

의존성 규칙을 준수하며 고수준의 정책을 저수준의 세부사항으로부터 분리하는 경계에 의해 정의됨.

 

단순히 애플리케이션의 행위를 서비스 단위로 나누는 것(서비스 기반 아키텍처)은,
서비스 간 협력이 필요할 때 함수 호출 비용만 증가시키는 결과를 낳을 수 있음.

---

서비스 기반 아키텍처에 대한 오해

1. 확장 가능한 시스템 = 서비스 기반 시스템이라는 등식은 성립하지 않음.
   • 모놀리식 기반 시스템도 대규모 시스템에 적합함을 입증한 기업들이 있음
2. 서비스는 항상 독립적으로 배포되지 않음.
   • 데이터나 로직이 강하게 결합된 경우, 해당 서비스들은 함께 개발·배포되어야 함

---

서비스 기반 Taxi 호출 아키텍처

Taxi Supplier

• 외부 택시 공급자 시스템 혹은 파트너사에서 실시간으로 택시 위치, 상태, 차량 정보 등을 제공
• Taxi Finder는 이들 Supplier로부터 데이터를 수집해 택시 후보군을 형성함

Taxi Finder

• 여러 Taxi Supplier의 현황을 검토하여 사용자에게 적합한 택시 후보들을 선별
• 해당 사용자에 할당된 단기 데이터 레코드에 후보 택시 정보를 저장

Taxi Selector

• 사용자가 지정한 비용, 시간, 고급 여부 등의 조건을 기초로 후보 택시 중에서 적합한 택시 선택
• 선택한 택시를 Taxi Dispatcher로 전달

Taxi Dispatcher

• 선택된 택시에 배차 지시를 내림

 

의존성 문제

• Taxi Selector → Taxi Dispatcher, Taxi Finder → Taxi Supplier
• 고수준 정책(Selector, Finder)이 저수준 세부사항(Dispatcher, Supplier)에 직접 의존

*고수준: 시스템의 비즈니스 규칙, 변경 가능성이 낮고 재사용 가능한 정책
(ex. Selector가 어떤 조건으로 택시를 고를지 결정)

*저수준: 구체적 구현 세부사항, 외부 API나 기술 요소, I/O에 가까움
(ex. Dispatcher가 어떻게 배차할지 구현, Supplier가 어떤 방식으로 위치 정보를 주는지 등)

 

신규 기능: 고양이 배달 추가 시 문제점

회사는 고양이 배달 기능을 추가하려 함. (야옹이 탑승 가능한 차량, 알레르기 여부 고려 등)

수정 포인트:

• Taxi Selector: 고양이 알레르기 여부, 최근 고양이 탑승 이력 등을 고려한 필터링 로직 필요
• Taxi Finder: 각 Supplier에서 고양이 수용 가능 차량 정보 수집 필요
• Taxi Dispatcher: 조건 충족 여부 확인 및 배차 실행 로직 수정
• Taxi Supplier: 고양이 관련 데이터 제공을 위한 API 및 스키마 수정

⇒ 모든 서비스가 서로 결합되어 있어, 하나의 기능을 추가하기 위해 모든 컴포넌트를 수정해야 함

"서비스 지향 구조라도, 아키텍처적 분리가 이루어지지 않으면 독립적 유지보수는 어렵다."

---

SOLID 원칙을 따르는 구조

• 의존성 규칙을 준수하게 수정
• 다형성으로 확장할 수 있는 클래스 집합을 생성 -> 새로운 기능 추가하기 편하게 함

---

서비스 기반 아키텍처에서도 이렇게 문제를 해결 할 수 있을까?

---

결론

아키텍처 경계를 정의하는 것은 서비스를 기반으로 나눠 관리하는 것이 아니다.

시스템의 아키텍처는 시스템 내부에 그어진 경계와 경계를 넘나드는 의존성에 의해 결정된다.

---

 

※ 본 글은 『Clean Architecture』(로버트 C. 마틴 저) 5부 27장을 기반으로 학습 목적으로 요약한 글입니다.

※ 이 글은 책의 내용을 요약한 것으로, 원문 없이 읽을 경우 오해의 여지가 있을 수 있습니다. 정확한 이해를 위해 원서의 정독을 권장합니다.