본문 바로가기
SW

클린 아키텍처:소프트웨어 구조와 설계의 원칙(Clean Architecture) - 5부 : 아키텍처 (27장)

by 라꾸스떼(YR) 2020. 3. 21.
반응형

[27장] '크고 작은 모든' 서비스들

서비스 지향 '아키텍처'와 마이크로서비스 '아키텍처'

 

[서비스 아키텍처?]

시스템의 아키텍처는 의존성 규칙을 준수하며 고수준의 정책을 저수준의 세부사항으로부터 분리하는 경계에 의해 정의된다. 서비스 그자체로는 아키텍처를 정의하지 않는다. 모노리틱 시스템이나 컴포넌트 기반 시스템에서 아키텍처를 정의하는 요소는 바로 의존성 규칙을 따르며 아키텍처 경계를 넘나드는 함수 호출들이다. 결국 서비스는 프로세스나 플랫폼 경계를 가로지르는 함수 호출에 지나지 않는다.

 

[서비스의 이점?]

<결합 분리의 오류>

시스템을 서비들로 분리함으로써 얻게 되리라 예상되는 큰 이점 하나는 서비스 사이의 결합이 확실히 분리된다는 점이다. 모든 서비스의 인터페이스는 반드시 잘 정의되어 있어야 한다.

서로 공유하는 데이터에 의해 이들 서비스는 강력하게 결합되어 버린다. 서비스들 사이는 서로 간접적으로 결합되어 버린다.

서비스 인터페이스가 함수 인터페이스보다 더 엄밀하거나, 더 엄격하고, 더 잘 정의되는 것은 아니다. 이러한 이점은 환상에 불과하다,

 

<개발 및 배포 독립성의 오류>

개발 및 배포 독립성은 확장 가능한 것으로 간주된다.

대규모 엔터프라이즈 시스템은 서비스 기반 시스템 이외에도, 모노리틱 시스템이나 컴포넌트 기반 시스템으로도 구축할 수 있다는 사실은 역사적으로 증명되어 왔다. '결합 분리의 오류'에 따르면 서비스라고 해서 항상 독립적으로 개발하고, 배포하며, 운영할 수 있는 것은 아니다.

 

[야옹이 문제]

확장 가능한 시스템을 구축하고 싶었기에, 우리는 수많은 작은 마이크로 서비스를 기반으로 구축하기로 결정했다. 개발팀 직원을 많은 소규모 티믕로 세분화했고, 각 팀이 팀 규모에 맞게 적당한 수의 서비스를 개발하고, 유지보수하며, 운영하는 책임을 지도록 했다.

기능을 구현하려면 이들 서비스 중 어디를 변경해야 할까? 전부다. 의심의 여지없이 야옹이 배달 기능을 추가하려면 개발과 배포 전략을 매우 신중하게 조정해야 한다. 다시 말해 이 서비스들을 모두 결합되어 있어서 독립적으로 개발하고, 배포하거나, 유지될 수 없다. 이게 바로 횡단 관심사(Cross-Cutting Concern)가 지닌 문제다.

 

[객체가 구출하다]

SOLID 설계 원칙을 잘 들여다보면, 다형적으로 확장할 수 있는 클래스 집합을 생성해 새로운 기능을 처리하도록 함을 알 수 있다.

추상 기반 클래스를 템플릿 메서드나 전략 패턴 등을 이용해서 오버라이드한다.

 

[컴포넌트 기반 서비스]

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

각 서비스의 내부는 자신만의 컴포넌트 설계로 되어 있어서 파생 클래스를 만드는 방식으로 신규 기능을 추가할 수 있다. 파생 클래스들은 각자의 컴포넌트 내부에 놓인다.

 

[횡단 관심사]

모든 주요 시스템이 직면하는 횡단 관심사를 처리하려면, 서비스 내부는 의존성 규칙도 준수하는 컴포넌트 아키텍처로 설계해야 한다. 아키텍처 경계를 정의하는 것은 서비스 내에 위치한 컴포넌트다.

 

[결론]

서비스는 시스템의 확장성과 개발 가능성 측면에서 유용하지만, 그 자체로는 아키텍처적으로 그리 중요한 요소는 아니다. 시스템의 아키텍처는 시스템 내부에 그어진 경계와 경계른 넘나드는 의존성에 의해 정의된다. 서비스는 단 하나의 아키텍처 경계로 둘러싸인 단일 컴포넌트로 만들 수 있다. 혹은 여러 아키텍처 경계로 분리된 다수의 컴포넌트로 구성할 수도 있다.

반응형

댓글