‘클린 아키텍처’ 기술 서적에 대해 학습했던 내용을 정리하기 위한 목적의 TIL 포스팅입니다.🙆♂️
서비스 아키텍처?
- 먼저 서비스를 사용한다는 것은 본질적으로 아키텍처에 해당하지 않는다.
- 시스템 아키텍처는
의존성 규칙을 준수하며 고수준의 정책을 저수준의 세부사항으로부터 분리하는 경계에 의해 정의된다. - 단순히 애플리케이션의 행위를 분리할 뿐인 서비스라면 값 비싼 함수호출에 불과하며, 아키텍처 관점에서 중요하다고 볼 수 는 없다.
- 시스템 아키텍처는
- 서비스는 프로세스나 플랫폼 경계를 가로지르는 함수 호출에 지나지 않는다.
- 아키텍처적으로 중요한 서비스도 있지만, 그렇지 않은 서비스도 있다.
- 아래에선 전자에 주목할 것이다.
서비스의 이점?
- 서비스 아키텍처에 대한 이의 제기 내용을 살펴보자.
결합 분리의 오류?
- 서비스 사이의 결합이 확실 분리되진 않는다.
- 프로세서 내의 또는 네트워크 상의 공유 자원 때문에 결합될 가능성이 여전히 존재한다.
- 서로 공유하는 데이터에 의해 이들 서비스는 강력하게 결합되어 버린다.
- 예를 들어, 서비스 사이를 오가는 데이터 레코드에 새로운 필드를 추가한다면, 이 필드를 사용해 동작하는 모든 서비스는 반드시 변경되어야 한다.
- 또한 이 서비스들은 이 필드에 담긴 데이터를 해석하는 방식을 사전에 완벽하게 조율해야 한다.
- 따라서 서비스들은 이 데이터 레코드에 강하게 결합되고 서비스들 사이는 서로 간접적으로 결합되버린다.
개발 및 배포 독립성의 오류
- 서비스 아키텍처는 시스템의 개발, 유지보수, 운영 또는 비슷한 수의 독립적인 팀 단위로 분할할 수 있다고 여긴다.
- 위는 일리는 있지만 극히 일부일 뿐이다.
- 첫째로, 대규모 엔터프라이즈 시스템은, 모노티틱 또는 컴포넌트 기반 시스템으로도 구축할 수 있다. (꼭 서비스 아키텍처가 아니어도 된다)
- 둘째로, ‘결합 분리의 오류’에 따르면 서비스라고 해서 항상 독립적으로 개발, 배포, 운영할 수 있는 것은 아니며 데이터나 행위에서 어느 정도 결합되어 있다면 결합된 정도에 맞게 개발, 배포, 운영을 조정해야만 한다.
야옹이 문제
- 이전 택시 통합 시스템을 보면 기능적으로 분해되어 있다.
- 그래서 야옹이 배달 기능이 추가된다 할경우 전부 다 변경이 필요하다.
- 독립적으로 개발하고 배포하거나 유지될 수 없다.
- 횡단 관심사가 가진 문제이며 서비스 지향이든 아니든 모든 소프트웨어가 이 문제에 직면하게 될 것이다.
객체가 구출하다
- 컴포넌트 기반 아키텍처에선 SOLID 설계원칙을 기반으로 다형적으로 확장할 수 있는 클래스 집합을 생성해 새로운 기능을 처리하도록 함을 알 수 있다.
- 이전 그림 27.1 의 서비스들과 거의 일치한다.
- 하지만 경계와 의존성 규칙을 준수한다는점에 주목하자.
- 배차에 특화되는 로직 부분은 Rides 컴포넌트로 추출되고 야옹이에 대한 신규 기능은 Kittens 컴포넌트에 들어갔다.
- 따라서 야옹이 기능은 결합이 분리되며, 독립적으로 개발, 배포할 수 있다.
컴포넌트 기반 서비스
- 서비스 또한 SOLID 설계 원칙대로 설계할 수 있으며 컴포넌트 구조를 갖출 수 있어 기존 컴포넌트를 변경하지 않고도 새로운 컴포넌트를 추가할 수 있다.
- 위 이미지는 서비스들의 존재는 이전과 달라진게 없지만, 각 서비스 내부는 자신만의 컴포넌트 설계로 되어 있어 파생클래스를 만드는 방식으로 신규 기능을 추가 가능하다. 파생 클래스들은 각자의 컴포넌트 내부에 놓인다.
횡단 관심사
- 횡단 관심사를 처리하려면 다이어그램처럼 서비스 내부의 의존성 규칙을 준수하는 컴포넌트 아키텍처로 설계되어야한다.
- 하나의 서비스 내부에서도 web 모듈, domain 모듈, 인프라스트럭쳐 모듈..
- 아키텍처 경계는 서비스 사이에 존재하지 않으며, 아키텍처 경계를 정의하는것은 서비스 내에 위치한 컴포넌트이다.
결론
- 서비스는 시스템의 확장성과 개발 가능성 측면에선 유용하다.
- 하지만 그자체로 아키텍처적으로 그리 중요한 요소는 아니다.
- 시스템 아키텍처내는 시스템 내부에 그어진 경계와 경계를 넘나드는 의존성에 의해 정의된다.
- 시스템의 구성 요소가 통신하고 실행되는 물리적인 메커니즘에 의해 아키텍처가 정의되는 것이 아니다.
- 서비스는 단 하나의 아키텍처 경계로 둘러싸인 단일 컴포넌트로 만들 수 있다.
- 혹은 여러 아키텍처 경계로 분리된 다수의 컴포넌트로 구성할 수도 있다.
- 드물게는 클라이언트와 서비스가 강하게 결합되어 아키텍처적으로 아무 의미 없을때도 있다.