[클린아키텍처] 26장 메인 컴포넌트, 27장 크고 작은 모든 서비스들

메인 Main 컴포넌트

: 시스템에서 나머지 컴포넌트를 생성하고, 조정하며 관리한다.

 

• 가장 낮은 수준의 정책
• 시스템의 초기 진입점
• 의존성 주입 프레임워크를 이용해 의존성을 주입한다.
• 입력 스트림 생성 부분, 게임의 메인 루프 처리, 간단한 입력 명령어 해석 등 처리, 명령어를 실제로 처리하는일은 다른 고수준 컴포넌트로 위임한다.
• 애플리케이션의 플러그인 (초기 조건과 설정을 구성하고, 외부 자원을 모두 수집한 후 제어권을 애플리케이션의 고수준 정책으로 넘기는 플러그인)
• 메인 컴포넌트를 둘 이상으로 만들 수 있다. ex) 개발용 메인 플러그인, 테스트용 메인 플러그인, 상용 메인 플러그인, 국가별 메인 플러그인, 영역별 메인 플러그인, 고객별 메인 플러그인

---

 

서비스 지향 아키텍처, 마이크로서비스 아키텍처가 인기 있는이유

• 서비스를 사용하면 상호 결합이 철저하게 분리되는 것처럼 보인다
• 서비스를 사용하면 개발과 배포 독립성을 지원하는 것처럼 보인다.

-> 일부만 맞다.

 

 

결합 분리의 오류

시스템을 서비스들로 분리하면 각 서비스는 서로 다른 프로세스에서 실행된다.

-> 서비스는 다른 서비스의 변수에 직접 접근할 수 없다.

-> 모든 서비스의 인터페이스는 반드시 잘 정의되어 있어야 한다.

-> But 서비스 인터페이스가 함수 인터페이스보다 더 잘 정의되는 것은 아니다.

 

 

개발 및 배포 독립성의 오류

데브옵스 전략에서 각 서비스를 작성하고 유지보수하며 운영하는 책임을 질 수 있다. (scalable)

-> 대규모 엔터프라이즈 시스템의 개발, 유지보수, 운영을 비슷한 수의 독립적인 팀 단위로 분할할 수 있다.

-> But 대규모 엔터프라이즈 시스템은 모노리틱 시스템, 컴포넌트 기반 시스템으로도 구축이 가능하다 그리고, 서비스라고 항상 독립적으로 개발, 배포, 운영 가능하지는 않다.

 

 

횡단 관심사 Cross-Cutting Concern 의 문제

-> 서비스들이 모두 결합되어 있어서 독립적으로 개발하고 배포하거나 유지될 수 없다

 

 

컴포넌트 기반 아키텍처에서는 횡단 관심사 문제를 어떻게 해결했을까?

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

 

 

1 야옹이 문제 - 기존 택시 서비스 다이어그램 -> 개선된 서비스 다이어그램

https://hwannny.tistory.com/46

 

 

2 야옹이 문제 - 객체 지향 방식으로 횡단 관심사 해결한 다이어그램

컴포넌트 아키텍처

https://sungjk.github.io/2019/11/05/clean-architecture-2.html

• 두 컴포넌트는 기존 컴포넌트에 있는 추상 클래스를 템플릿 메서드나 전략 패턴 등을 이용해서 오버라이드 한다.
  • 컴포넌트 1. Rides -  배차에 특화된 로직
  • 컴포넌트 2. Kittens - 야옹이에 대한 신규 기능

• UI의 제어하에 팩토리(factories)가 클래스들을 생성한다

 

 

3 야옹이 문제 - 개선된 서비스 다이어그램

 https://sungjk.github.io/2019/11/05/clean-architecture-2.html

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

 

 

컴포넌트 아키텍처 다이어그램

https://sungjk.github.io/2019/11/05/clean-architecture-2.html

• 서비스 내부는 의존성 규칙도 준수하는 컴포넌트 아키텍처로 설계해야 한다.