서론
- 아키텍처의 모든 것은 트레이드 오프다
- 현대의 아키텍처 스타일은 단계적으로 구축한다는 개념에 기반하기 때문에 구조를 변경하는 작업은 예전만큼 비싸지 않다 → 현대적이라는 가정하에…
- 아키텍처
- 아키텍처 구조/특성/결정/설계 원칙이 결합된 구조를 말한다
- 구조: 아키텍처 스타일 ex) 마이크로 서비스, 레이어드 등등
- 특성: 기능과 직교하는 시스템의 성공 기준을 결정한다 ex ) 신뢰성, 가용성, 보안, 성능 등등
- 결정: 시스템의 제약 조건. ex ) 개발자가 해야 할것/ 하지 말아야 할 것의 결정
- 설계 원칙: 개발 가이드 라인 ex ) 서비스 간 통신은 비동기 메시징으로 처리한다
- 아키텍트
- 아키텍처 결정 가이드/ 분석/ 트렌트 유지에 관한 작업을 한다
- 비즈니스 도메인에 대한 이해 및 다양한 기술/ 경험을 토대로 컴플라이언스(원칙)를 준수한다
관점
- 개발자와는 다른 관점으로 시스템을 봐야 한다 → 기술의 깊이 보다는 폭이 중요하다
- 아키텍처와 설계는 동기화되어 이터레이션마다 변화해야 한다
- 코딩 실무와 균형을 맞추는 방법
- 비즈니스 공통 기능을 코딩하는 쪽에 맞추어 1~3회 이터레이션
- 특정 기술 둘 중 선택해야 할 때는 POC를 자주 한다 → 프로덕션 레벨의 코드로 테스트
- 기술 부채나 아키텍처와 관련된 코딩을 한다
아키텍처 특성
- 비 도메인 설계 고려 사항, 구조적 측면이 중요하다
- 최고를 고집하지 말고 나쁜 것 중 가장 나은 아키텍처를 선정하라
- 모든 아키텍처 특성을 지원하는 제네릭 아키텍처를 만들지 마라
- 특성 도출을 위한 출처
- 도메인 관심사
- 요구사항/ 명시적 특성
- 암묵적 특성
- 아키텍처 퀀텀
- 높은 기능 응집도와 동기적 커네이선스를 가진, 독립적으로 배포 가능한 아티팩트
- EX) 모노리스 API + DB + REDIS = 1 퀀텀 , 마이크로 서비스 = N 퀀텀
모듈성
-
복잡한 구조를 만드는 데 쓰이는 각각의 표준화한 부품이나 독립적 단위
-
모듈성 측정 → 아래로 갈수록 점점 나쁜 응집도를 가진다
- 기능적: 기능 상 꼭 필요한 모든 것이 들어있는가?
- 순차적: 한쪽이 데이터를 출력하면 반대쪽이 입력 받는 형태로 동작하는가?
- 소통적: 모듈이 각자 정보에 따라 동작하거나 출력을 내는 통신 체인이 형성됬는가?
- 절차적: 정해진 순서대로 모듈이 동작해야 하는가?
- 일시적: 특정 시점/순서에 따라 모듈들이 동작해야 하는가?
- 논리적: 기능적이 아닌 논리적으로 연관되어있는가? EX ) StringUtil, NumberUtil 등등
- 동시적: 연관이 없는데 같이 존재한다
-
측정 방법
- 구조적 응집도: LCOM 계산 방법 → 높을 수록 좋음
- 추상도: abstract class / concreate class → 높을 수록 추상 모듈에 가까움
- 불안정도: 원심/ (구심 + 원심) → 불안정도가 높을 수록 커플링이 높다
- 원심: 나를 참조하는 객체의 수
- 구심: 내가 참조하는 객체의 수
- 메인 시퀀스로부터 거리: 추상도와 불안정도 사이의 이상적인 관계를 나타내는 2차원 그래프
- 불 안정도와 추상도가 낮을 수록 변경에 취약한 코드가 된다
- 불 안정도와 추상도가 너무 높다면 추상화가 너무 심해 사용하기 어려운 코드가 된다
- 커네이선스
- 한 쪽이 변경될 때 반대쪽을 변경해야 전체 시스템의 정합성이 맞는 모듈의 관계
- 개선 방법
- 캡슐화한 요소로 모듈을 쪼개 전체 커네이선스를 줄인다
- 경계를 벗어난 커네이선스를 최소화한다
- 경계 내부에서는 커네이선스를 최대화 한다
컴포넌트
- 모듈을 물리적으로 패키징한 것
- 아키텍트는 큰 단위의 컴포넌트 식별에 참여하게 된다
- 아키텍트는 클래스 설계에 참여해서도 안되고 시스템의 세세한 설계 결정에 관여해서도 안된다
- 컴포넌트 내부 분할 방식
- 도메인 분할 ( 모듈러 모놀리스 )
- 도메인에 따라 분할된 단일 배포 단위
- 도메인 별 다목적 팀 구성 가능
- 메시지 흐름이 문제 영역과 일치된다
- 공통 정의 코드가 여러 군데로 분산되기 쉽다
- 기술 분할 ( 레이어드 )
- 커스텀 코드가 명확하게 분리된다
- 전역 커플링이 더 높다
- 데이터 레벨의 커플링이 더 높다
- 도메인 분할 ( 모듈러 모놀리스 )
- 컴포넌트 단위 분할 방식
- 액터/액션
- 액터와 액션을 식별하고 그에 따라 분리
- 선형 설계 시 매우 유리
- 이벤트 스토밍
- 이벤트와 메시지 핸들러 중심으로 단위 분할
- 워크플로
- 이벤트 스토밍의 대안으로 핵심 역할을 식별하고 이 역할이 관여하는 워크플로 유형을 결정하여 분할
- 액터/액션
아키텍처 스타일
- 아키텍처 스타일 vs 패턴
- 기본적으로 쉬운 동기 통신을 이용하고 필요할 때 비동기 통신을 사용하라
- 모놀리식 아키텍처 종류
- 분산형 아키텍처