아키텍처 관점으로 중요한 서비스도 있지만, 그렇지 않은 서비스도 존재한다.
→ 저자는 중요한 서비스에 대해 관심을 가진다.
서비스의 이점?
서비스 아키텍처에 대해 이의 제기.
결합 분리의 오류
이점1. 서비스를 분리함으로써 통해 상호 결합이 확실히 분리된다고 본다.
그러나 서비스 프로세서의 네트워크 상 공유 자원 때문에 결합될 가능성은 여전히 존재한다.
- 공유되는 데이터 레코드에 새로운 필드를 추가한다면, 필드를 사용하는 서비스는 반드시 변경되어야한다.
- 서비스들은 이 필드에 담긴 데이터를 해석하는 방식을 사전에 완벽하게 조율해야한다.
따라서 서비스들은 레코드에 강하게 결합되고, 서비스들 사이는 간접적으로 결합되어 버린다.
개발 및 배포 독립성의 오류
이점2. 시스템을 독립적으로 개발하고, 배포 가능한 수십/수백/수천 개의 서비스들을 이용해 만들 수 있다고 믿는다.
그러나
- 서비스 기반이 확장 가능한 시스템을 구축하는 유일한 선택지가 아니다.
- ‘결합 분리 오류'에 따르면 서비스라고 해서 항상 독립적으로 개발, 배포, 운영할 수 있는 것은 아니다.
야옹이 문제
‘결합 분리 오류', ‘개발 및 배포 독립성의 오류’에 대한 예
TaxiFinder: TaxiSupplier를 검토해 택시 후보 선별
TaxiSelector: 사용자의 요구 조건에 따라 후보 중 적합한 택시 선택
TaxiDispatcher: 해당 택시에 배차 지시
택시 통합 시스템이 각각의 서비스별로 나뉘어 개발, 운영되고 있다.
만약 야옹이 배달 서비스를 추가하겠다고 한다면?
- 서비스들이 모두 결합되어 있기 때문에 전부 변경해야하는 문제 발생
- 독립적으로 개발, 배포, 유지될 수 없다.
→ 모든 소프트웨어의 횡단 관심사가 지닌 문제
- 횡단 관심사란? 하나의 기능 자체에 공통적으로 들어가는 로직
왜 여기서 횡단 관심사 문제가 발생했을까? (개인적인 생각)
: 택시 서비스, 야옹이 배달 서비스 둘의 공통 로직을 구현하고, 변경할 때 서비스 전부를 변경해야하기 때문에
객체가 구출하다
컴포넌트 기반 아키텍처에서 이 문제를 해결한다면?
배차에 특화된 로직 부분은 Rides 컴포넌트로 추출, 야옹이의 신규 기능은 Kittens 컴포넌트에 들어감
두 컴포넌트 모두 의존성 규칙 준수
- 다형적으로 확장할 수 있는 클래스 집합을 생성해 새로운 야옹이 문제를 처리했다.
- 야옹이 기능은 결합이 분리되며, 독립적으로 개발하여 배포할 수 있다.
컴포넌트 기반 서비스
서비스도 객체 지향 방식처럼 해결할 수 있을까? 🙆🏻♀️
서비스 또한 SOLID 원칙대로 설계할 수 있으며 컴포넌트 구조를 갖출 수도 있다.
- 서비스 내부는 자신만의 컴포넌트 설계로 되어 있어, 파생 클래스를 만들어 신규 기능을 추가할 수 있다.
→ 변경에는 닫혀 있고, 확장에는 열려있는 ‘개방 폐쇄 원칙' 준수
횡단 관심사
횡단 관심사를 처리하려면, 서비스 내부는 의존성 규칙도 준수하는 컴포넌트 아키텍처로 설계해야 한다.
→ 아키텍처 경계를 정의하는 것은 서비스가 아닌, 서비스 내 위치한 컴포넌트다.
결론
서비스 자체로는 아키텍처적으로 중요한 요소는 아니다.
서비스를 단일 컴포넌트로 만들거나, 다수의 컴포넌트로 구성되는 컴포넌트 기반 서비스를 만들어야 한다.
