특성 : 가용성, 신뢰성, 확장성, 보안, 민첩성, 탄력성, 복구성, 성능, 배포, 학습 (시스템이 가져야 할 특성)
결정 : 제약조건, 개발자가 해도 되는 것과 하지 말아야 할 것 정의 (청사진)
설계 원칙 : 아키텍처 결정을 만족시키는 가이드라인
시스템 구조 : 아키텍처 결정 및 설계 원칙에 적합한 상위 수중의 시스템 구조를 정의 (System 전체 구조도)


레이어드 아키텍처 스타일
사실상 표준 아키텍처
관심사의 분리
기술 분할
아키텍처 결정사항 : 레이어 개방 / 폐쇄 여부
아키텍처 싱크홀 안티 패턴

byPass 단순 흐름 -> 바로 근접한 layer 열려 있고, layer가 멀면 open X
MVC Pattern (Model, View, Controller)
프레젠테이션 레이어(presentation)이 보내주는게 Model, Controller -> 레이어드 적용 X
파이프라인 아키텍처 스타일
Bash, Zsh 등 유닉스 터미널 쉘 언어의 기초 원리
• 프로듀서 (Producer) : 프로세스 시작점 , 소스
• 변환기(transformer) : 입력을 받아 일부 또는 전체를 변환 한 후 전달, map
• 테스터(tester) : 기준에 따라 테스트 , 결과 생산, reduce
• 컨슈머(consumer) : 흐름 종착역, 데이터베이스 저장, 화면 출력

마이크로 커널 아키텍처 스타일
Solutuion이나 tool
플러그인(plug-in) 아키텍처 (이클립스 -> System 기능 추가)

서비스 기반 아키텍처 스타일(1/5)
class 여러개 묶은 개념 = component
component + component + ... + = Service

• 유연성 있는 대규모 분산 레이어 구조
• 도메인 서비스 보통 4~12개 , 평균7개
• REST,RPC,SOAP
• 중앙 공유 데이터베이스 사용 (조인 기능 사용)
• 신뢰성, 내 고장성
서비스 기반 아키텍처 스타일 (2/5)
유저 인터페이스 변형

서비스 기반 아키텍처 스타일 (3/5)
DB 변형
개별 데이터베이스로 분리
각 DB에 있는 도메인 데이터들이 다른 도메인의 서비스가 필요하지 않도록 설계
통합 DB, 도메인별 DB , 조회용DB , 서비스별 DB격리

서비스 기반 아키텍처 스타일 (4/5)
레이어드 설계 vs 도메인 설계
세분도가 크기 때문에 API 퍼사드를 통한 내부 클래스 수준의 오케스르레이션 필요

서비스 기반 아키텍처 스타일 (5/5)
Data Owner ship을 나눈 아키텍처

이벤트 기반 아키텍처 스타일
확정성 뛰어나고, 고성능 애플리케이션 개발에 널리 쓰이는 비동기 분산 아키텍처
동기 : Response -> Request (답 올때 까지 대기) / 의존성이 높음 / 동기통신을 하게 되면 의존성이 높음
비동기 : Response 기다리지 X, 내 할일을 하고 던지는 것 = Locking을 유발 X
SOA나 MSA는 조각으로 나뉘고, 각각의 Network 나눠 처리 -> 통신 문제는 항상 유발
RabbitMQ, ActiveMQ등 경량 메시지 브로커
장점 : 성능, 응답성, 확장성 (의존성이 없기 때문에 확장 유리)
단점 : 트랜잭션 통제 어려움, 교착상태, 데이터비일관성 (본인꺼 처리후 비동기 상태로 던짐), 에러 처리 어려움

중재자 토폴로지
이벤트 사건이 아니라 커멘드
장점: 오케스트레이션, 에러 처리
단점: 확장성, 중재자가 병목 지점, 커플링으로 성능 저하

공간 기반 아키텍처 스타일
사용자가 많이 몰릴때 필요한 부분만 확장 가능
높은 확장성, 탄력성, 동시성
동시 유저수가 매우 가변적이라 예측조차 곤란한 애플리케이션에 유용

오케스트레이션 기반 서비스 지향 아키텍처 스타일
서비스 기반 아케텍처 실패 case, 재사용성을 너무 높이다 보니 응집도가 높아짐

마이크로서비스 기반 아키텍처 스타일
분산 아키텍처, 서능적으로 봤을때는 별로, 세분화의 중요
데이터 격리, 재사용 보다는 중복
API레이어 , 고도의 디커플링 추구
