HomeAboutMeBlogGuest
© 2025 Sejin Cha. All rights reserved.
Built with Next.js, deployed on Vercel
[New] 아만드팀
[New] 아만드팀
/
🔏
팀 스터디
/
🪵
클린 아키텍처
/
📎
27 크고 작은 모든 서비스들
📎

27 크고 작은 모든 서비스들

발표자
Subin kim
Date
Jul 20, 2022
Tags
5부
아키텍처

서비스 아키텍처

시스템의 아키텍처는 1. 의존성 규칙을 준수하며 2. 고수준의 정책을 저수준의 세부사항으로부터 분리하는 경계에 의해 정의된다

시스템에서 아키텍처를 정의하는 요소

  • 의존성 규칙을 따르며 아키텍처 경계를 넘나드는 함수 호출들
  • 단순히 애플리 케이션의 행위를 분리할 뿐인 서비스
    • → 값비싼 함수 호출에 불과. 아키텍처적으로는 전혀 중요하지 않다.

서비스의 이점?

시스템을 서비스로 분리하면서 얻게되는 이점
결합 분리의 오류
  • 서비스 사이의 결합이 확실히 분리된다
    • 각 서비스는 서로 다른 프로세서, 심지어는 서로 다른 프로세서에서 실행된다??? 253p
    • 반박
      • 개별 변수 수준에서는 각각 결합이 분리된다는 점
        • 프로세서 또는 네트워크 상 공유자원에 의해 결합될 가능성이 여전히 존재
        • ex) 서비스 사이를 오가는 데이터 레코드에 새로운 필드를 추가한다면, 이 필드를 사용해 동작하는 모든 서비스는 반드시 변경해야 됨
      • 인터페이스가 잘 정의되어 있다는 점?
        • 이런 이점은 환상에 불과함
          • 함수나, 서비스 인터페이스나 똑같다
개발 및 배포 독립성의 오류
  • 전담팀이 서비스를 소유하고 운영한다
    • 전담팀에서 각 서비스를 작성하고, 유지보수하며, 운영하는 책임을 질 수 있음
    • 이러한 개발 및 배포 독립성은 확장 가능한 것으로 간주됨
    • 대규모 시스템이 독립적으로 개발, 배포 가능 → 보다 쉽게 수많은 서비스 제공 가능
      • 시스템의 수 == 독립적인 팀 단위 (로 쪼갤 수 있다고 믿음)
      반박
    • 극히 일부일 뿐이다
      • 대규모 시스템은 서비스 기반 시스템 은 확장 가능한 시스템을 구축하는 유일한 선택지가 아님. ( 모노리틱 시스템이나 컴포넌트 기반 시스템으로도 구축할 수 있음)
      • 결합 분리의 오류에 따르면 서비스라고 해서 항상 독립적으로 개발하고, 배포하여, 운영할 수 있는 것은 아님. 데이터나 행위에서 어느정도 결합되어 있다면 결합된 정도에 맞게 개발, 배포, 운영을 조정해야만 함

야옹이 문제

택시 통합 시스템

요구사항
  • 시스템은 해당 도시에 운영되는 많은 택시 업체를 알고 있음
  • 고객은 승차 요청을 할 수 있음
  • 고객은 다양한 기준에 따라 택시를 선택할 수 있음
    • 승차시간, 비용, 고급 택시여부, 운전사 경력 등
 
  1. MSA 아키텍처로 구축하기로 결정
      • 확장 가능한 시스템을 구축하고 싶었기 때문
  1. 소규모 팀으로 세분화
      • 팀 규모에 맞게 적당한 수의 서비스를 개발ㆍ유지보수ㆍ운영하는 책임을 지님
  1. 가상의 아키텍트가 서비스를 배치
    1. notion image
  1. 화창하고 기분 좋은날 마케팅 부서에서 야옹이 배달 서비스 기획을 발표
    1. 추가 요구사항
      • 사용자는 자신의 집이나 사무실로 야옹이를 배달해달라고 주문할 수 있다.
      • 회사는 도시 전역에 야옹이를 태울 다수의 승차 지점을 설정해야 할 것이다.
      • 야옹이 배달 주문이 오면 근처의 택시가 선택되고, 승차 지점 중 한 곳에서 야옹이를 태운 후, 올바른 주소로 야옹이를 배달해야 한다.
      • 택시 업체들은 해당 프로그램에 참여하거나 거부할 수 있다.
      • 고양이 알러지가 있는 운전자는 해당 서비스에서 제외되어야 한다
      • 지난 3일 사이 야옹이를 배달했던 차는 알러지가 있는 고객에게 배차되면 안된다
       

      Q. 어디를 변경해야 할까?

      이 서비스들은 모두 결합되어 있어서 독립적으로 개발하고, 배포하거나 유지될 수 없다.
      → 횡단 관심사가 지닌 문제
       

객체가 구출하다

컴포넌트 기반 아키텍처에서는 이 문제를 다음과 같이 해결한다
notion image

컴포넌트 기반 서비스

서비스가 반드시 소규모 단일체여야 할 이유는 없다
notion image
서비스는 SOLID 원칙대로 설계할 수 있으며, 컴포넌트 구조를 갖출수도 있다.
  • 서비스 내의 기존 컴포넌트들을 변경하지 않고도 새로운 컴포넌트를 추가할 수 있다
notion image
자바의 경우 서비스를 하나 이상의 jar 파일에 포함되는 추상클래스의 집합이라고 생각해라
 

횡단 관심사

아키텍처 경계가 서비스 사이에 있지 않다.
서비스를 관통하며, 서비스를 (아키텍처에 의해?) 컴포넌트 단위로 분할한다.

결론

서비스는 그 자체로는 아키텍처적으로 그리 중요한 요소는 아니다.
시스템의 아키텍처는 시스템 내부에 그어진 경계 와 경계를 넘나드는 의존성에 의해 정의된다.
 

방해하는 문장 - 2ㅎㅎ