서비스 아키텍처
시스템의 아키텍처는 1. 의존성 규칙을 준수하며 2. 고수준의 정책을 저수준의 세부사항으로부터 분리하는 경계에 의해 정의된다
시스템에서 아키텍처를 정의하는 요소
- 의존성 규칙을 따르며 아키텍처 경계를 넘나드는 함수 호출들
- 단순히 애플리 케이션의 행위를 분리할 뿐인 서비스
- → 값비싼 함수 호출에 불과. 아키텍처적으로는 전혀 중요하지 않다.
서비스의 이점?
시스템을 서비스로 분리하면서 얻게되는 이점
결합 분리의 오류
- 서비스 사이의 결합이 확실히 분리된다
- 각 서비스는 서로 다른 프로세서, 심지어는 서로 다른 프로세서에서 실행된다??? 253p
- 개별 변수 수준에서는 각각 결합이 분리된다는 점
- 프로세서 또는 네트워크 상 공유자원에 의해 결합될 가능성이 여전히 존재
- ex) 서비스 사이를 오가는 데이터 레코드에 새로운 필드를 추가한다면, 이 필드를 사용해 동작하는 모든 서비스는 반드시 변경해야 됨
- 인터페이스가 잘 정의되어 있다는 점?
- 이런 이점은 환상에 불과함
- 함수나, 서비스 인터페이스나 똑같다
반박
개발 및 배포 독립성의 오류
- 전담팀이 서비스를 소유하고 운영한다
- 전담팀에서 각 서비스를 작성하고, 유지보수하며, 운영하는 책임을 질 수 있음
- 이러한 개발 및 배포 독립성은 확장 가능한 것으로 간주됨
- 대규모 시스템이 독립적으로 개발, 배포 가능 → 보다 쉽게 수많은 서비스 제공 가능
- 시스템의 수 == 독립적인 팀 단위 (로 쪼갤 수 있다고 믿음)
- 극히 일부일 뿐이다
- 대규모 시스템은
서비스 기반 시스템
은 확장 가능한 시스템을 구축하는 유일한 선택지가 아님. (모노리틱 시스템
이나컴포넌트 기반 시스템
으로도 구축할 수 있음) 결합 분리의 오류
에 따르면 서비스라고 해서 항상 독립적으로 개발하고, 배포하여, 운영할 수 있는 것은 아님. 데이터나 행위에서 어느정도 결합되어 있다면 결합된 정도에 맞게 개발, 배포, 운영을 조정해야만 함
반박
야옹이 문제
택시 통합 시스템
요구사항
- 시스템은 해당 도시에 운영되는 많은 택시 업체를 알고 있음
- 고객은 승차 요청을 할 수 있음
- 고객은 다양한 기준에 따라 택시를 선택할 수 있음
- 승차시간, 비용, 고급 택시여부, 운전사 경력 등
- MSA 아키텍처로 구축하기로 결정
- 확장 가능한 시스템을 구축하고 싶었기 때문
- 소규모 팀으로 세분화
- 팀 규모에 맞게 적당한 수의 서비스를 개발ㆍ유지보수ㆍ운영하는 책임을 지님
- 가상의 아키텍트가 서비스를 배치

- 화창하고 기분 좋은날 마케팅 부서에서 야옹이 배달 서비스 기획을 발표
- 사용자는 자신의 집이나 사무실로 야옹이를 배달해달라고 주문할 수 있다.
- 회사는 도시 전역에 야옹이를 태울 다수의 승차 지점을 설정해야 할 것이다.
- 야옹이 배달 주문이 오면 근처의 택시가 선택되고, 승차 지점 중 한 곳에서 야옹이를 태운 후, 올바른 주소로 야옹이를 배달해야 한다.
- 택시 업체들은 해당 프로그램에 참여하거나 거부할 수 있다.
- 고양이 알러지가 있는 운전자는 해당 서비스에서 제외되어야 한다
- 지난 3일 사이 야옹이를 배달했던 차는 알러지가 있는 고객에게 배차되면 안된다
추가 요구사항
Q. 어디를 변경해야 할까?
이 서비스들은 모두 결합되어 있어서 독립적으로 개발하고, 배포하거나 유지될 수 없다.
→
횡단 관심사
가 지닌 문제객체가 구출하다
컴포넌트 기반 아키텍처에서는 이 문제를 다음과 같이 해결한다

컴포넌트 기반 서비스
서비스가 반드시 소규모 단일체여야 할 이유는 없다

서비스는 SOLID 원칙대로 설계할 수 있으며, 컴포넌트 구조를 갖출수도 있다.
- 서비스 내의 기존 컴포넌트들을 변경하지 않고도 새로운 컴포넌트를 추가할 수 있다

자바의 경우
서비스
를 하나 이상의 jar 파일에 포함되는 추상클래스의 집합
이라고 생각해라횡단 관심사
아키텍처 경계가 서비스 사이에 있지 않다.
서비스를 관통하며, 서비스를 (아키텍처에 의해?) 컴포넌트 단위로 분할한다.
결론
결론
서비스는 그 자체로는 아키텍처적으로 그리 중요한 요소는 아니다.
시스템의 아키텍처는 시스템 내부에 그어진
경계
와 경계를 넘나드는 의존성
에 의해 정의된다.방해하는 문장 - 2ㅎㅎ