Programming Architecture Cheat Sheet

패턴 - 추상팩토리

개요	구체적인 서브클래스들을 의존하지 않고, 여러 클래스 집단을 생성하기 위한 인터페이스
언제	객체들이 생성되는 것을 변경하게 하고 싶을 때, 관련된 여러 객체들이 함께 사용되어야 할 때, 여러 Product 군 중에서 하나를 선택해야 할때
참여자	AbstactFactory, ConcreteFactory, AbstractProduct, ConcreteProduct,Client
장점	구체 클래스를 client에서 분리, Product 그룹을 쉽게 교체, Product 그룹의 객체들 간의 일관성
단점	전혀다른 새로운 제품 제공이 어렵다.

패턴 - 빌더

언제	복잡한 객체들을 생성하는데 그 객체가 하나의 ADT로 나올 수 있을 때, 객체의 생성방법이 복잡하지만 동일한 생성API를 제공하고 싶을 때
참여자	Builder=생성API, ConcreteBuilder=실제생성, Director=생성workflow, Product=제품의ADT
장점	Product의 생성 로직을 변경할 수 있다, 생성과 Product 클래스를 코드 분리

추상팩토리 vs 빌더

추상팩토리	확장성에 관심, 매 생성시마다 객체가 나옴
빌더	복잡한 객체 생성을 단계별로 쪼개는 데 관심, 내부적으로 모든 작업이 끝난 뒤, 마지막에 하나의 객체가 생성 됨

패턴 - 책임 연쇄

뭐냐	UI event handling
언제	msg receiver들이 다수로 구성되어있고 누가 처리할 지 모를때, msg를 누가 처리할지 정하고 싶지 않을때
참여자	Handler(다른 Handler를 링크), ConcreteHandler
장점	msg receiver, sender의 결합이 낮아짐(= 동적으로 삭제/추가해도 무방하다는 것)
단점	msg가 반드시 처리되지는 않음,

패턴 - 반복자

뭐냐	Container의 구조를 노출하지 않고 구성요소를 순회하게 하는 것
언제	container의 내부구조를 노출하고 싶지 않을 때, 구성 요소를 순회하는 단일 API를 제공하고 싶을 때, 순회방법을 여러개 추가하고 싶을때
참여자	Aggregate(Container ADT), ConcreteAggregator, Iterator, ConcreteIterator

패턴 - Command

뭐냐	요청을 객체화
언제	요청을 지연하거나, 요청을 분산처리, 요청을 되돌리거나
참여자	Command(요청의 API), ConcreteCommand, Invoker(명령을 하나씩 처리), Receiver(client에게 알려줌)
장점	요청 추가가 쉽다, 요청을 지연,분산,undo 가능

패턴 - 팩토리메소드

언제	객체의 생성 시점을 client가 정해야 할때, 어떤 클래스를 생성해야 하는지는 서브클래스가 정하게 하고 싶을때
참여자	Product, ConcreteProduct, Creator, ConcreteCreator
장점	생성될 객체를 외부에서 변경할 수 있다.
단점	Product와 Creator 양쪽에 서브클래스를 하게 된다.

패턴 - Adapter

언제	어느 클래스의 인터페이스를 client가 원하는 인터페이스로 변경해야 할 때, 그런데 그 클래스를 수정할 수는 없을 때
참여자	ObjectAdapter(위임), ClassAdpater(다중상속) 2개 버전이 있다. Target=사용자가 바라보는 인터페이스, Adapter, Adaptee(문제아)

Adapter vs Proxy

Adapter는 기존과 다른 interface로 변형 vs proxy는 realSubject와 동일한 인터페이스를 redirection

Proxy는 객체에 대한 접근을 관리하는 것.

패턴 - 브릿지

뭐냐	구현과 추상을 분리해서 서로 조합하게 함.
언제	추상과 구현을 분리할 때, 구현을 런타임에 변경하고 싶을 때,
참여자	Abstraction, RefinedAbstraction(확장된 client가 사용할 API), Implementor(구현부의 ADT), ConcreteImplementor
장점	구현이 인터페이스에 얽매이지 않게 됨, 추상과 구현을 각각 확장 가능,상세한 구현을 숨김

Adapter vs Bridge

구조적으로는 서로 똑같음. 목적이 다르다. client가 사용할 수 있도록 인터페이스를 맞추는 것. Bridge는 추상과 구현이 얽매이지 않도록 함.

패턴 - Mediator

뭐냐	복합객체의 workflow를 확장할 수 있도록 한 객체에 몰아주는 것.
언제	메소드 안에 복합객체가 여러 객체들간 interaction이 존재할 때, 각 객체들이 다른 객체와 많은 분산된 interaction이 존재할 때
참여자	Mediator, ConcreteMediator, Colleague, ConcretreColleague
장점	다른 객체를 접근하고 제어하는 코드는 모두 Mediator에 통합, 다른 객체들 간의 종속성을 줄어듬, 제어가 중앙집중적, Mediator를 상속해서 제어를 쉽게 수정

Facade vs Mediator

Facade는 편한 Interface 사용이 목적 vs Mediator는 객체간 interaction을 가운데서 통제하자.

Facade는 새로운 객체 추가하려면 수정 필요 vs Mediator는 필요 없음.

패턴 - State

언제	객체의 상태에 따라서 런타임에 행동이 달라져야 할때, if-else가 가 너무 많을때
참여자	Context(client의 API), State, ConcreteState
장점	특정 state와 관련된 코드를 별도로 모아둘 수 있다, State를 명확하게 구분하고 state전이를 두드러지 게 한다.

패턴 - Composite

뭐냐	객체의 트리구조를 하나의 클래스로 구성하는 것
언제	트리구조를 만들어야 하는데, 모든 구성요소를 하나의 API로 다룰 수 있도록 하고 싶을때
참여자	Component(client가 사용하는 객체 합성 API를 가짐), Leaf(합성이외에 객체를 행동을 정의), Composite(자식을 Component르 가질 수 있도록 API를 구현함)
장점	client 코드가 단순해짐, 일관된 클래스 hierarchy가 나옴
단점	너무 범용적이라 특수화 된 코드를 넣기가 어려움(자식을 1개만 두고 싶다, 새로운 메소드 추가 등)

패턴 - Visitor

뭐냐	복합객체의 구조와 코드를 유지하면서 외부에서 그 요소에 대한 연산을 수행할 수 있다.
언제	객체의 구조의 요소들이 서로 다른 클래스일 때, 클래스마다 다른 연산을 적용해야 할때, 해당 클래스들은 코드 수정하고 싶지 않을때, 이러한 추가 연산이 앞으로도 또 일어날 때
구조	Visitor, ConcreteVisitor, Element, ConcreteElement
장점	새로운 연산을 쉽게 추가한다, 관련 연산을 추가할때 한군데에 모아둘 수 있다
단점	새로운 ConcreteElement 추가하면 모든 Visitor를 다 수정해야 한다.

패턴 - Observer

참여자	Subject(여러개의 Observer를 가지며, notify()가 불려지면 observer들에게 통보한다), ConcreteSubject, Observer, ConcreteObserver(subject로부터 상태가 변경되었다고 받으면 ConcreteSubject에게 notify 한다.)
장점	1:N 의 sender, receiver 구조를 가질 수 있다, 동적으로 변경할 수 있다,

패턴 - Strategy

언제	동적으로 알고리즘 교체, 클래스가 같아도 알고리즘은 달라야 할때, 알고리즘의 추가를 고려할때
참여자	Context(client의 API), Strategy, ConcreteStategy
장점	상속을 사용하지 않으므로 알고리즘을 변경하기 위해서 서브클래싱을 찍어내는 걸 안해도 된다, 조건문이 사라짐, 동적으로 알고리즘 선택
단점	사용자가 각 전략들이 무엇인지 알고있어야 한다, 어떠한 ConcreteStategy는 Stategy로 넘어온 인자가 필요없는 오버헤드가 있을 수 있다, 객체 수가 증가한다.

SOLID - Single Responsibility Principle

정의	한 클래스는 하나의 책임만 가져야 한다.
안되면?	책임이 결합된다. 분리되어 있으면 일부만 수정한 부분을 조합해서 재사용이 가능했을 것이다.

SOLID - Open Closed Principle

정의	확장에 열려있고, 수정에 닫혀있어야 한다.

SOLID - Liskov substituion principle

SOLID - Interface Segregation principle

뭐야?	사용자가 사용하지 않는 메소드에 의존하도록 해서는 안된다.
어떻게 해결?	다중 상속 (mixin, interface), Delegation

SOLID - Dependency Inversion Principle

뭐야?	'구현에 의존하지 말고, 추상화에 의존하자. 상위 수준(ADT)은 하위수준(구체클래스)에 의존해서는 안된다.

Coupling vs Cohension

결합도 -> 코드가 딱 붙어 의존상태가 강한 정도 (상속, Composition, 등) 낮을수록 좋다

응집도 -> 클래스가 하나의 책임에 대해 관련 있는 코드만 잘 모여져 있는가. 관련 없는 메소드가 많이 모여 있거나, 책임이 너무 많이 모여있으면 응집도가 떨어진다.

요구공학

요구공학	System Service (FR)과 Context(NFR)을 찾고 정리하는 것
SDLC의 종류	Water fall, Incremental, Evolutionary, Spiral Iterative, Agile, RUP
RUP의 프로세스	Inception, elaboration, construction, transition
Incremental의 프로세스	RE는 RE만, code 팀은 code만, Test팀은 Test만 파이프라인 처럼
Validation vs Verification	Verification은 명세대로 했는가, Validation은 명세가 올바른가
RE의 과정	Feasibility Test > RE Elicitation > Req Specification > Req Validation
Elicitation	System model을 만들고 Workshop, Brainstorming, survey, interview, role playing, prototyping 등을 해서 요구사항을 뽑아낸다. Prioritization&Negotiation으로 NFR에 대해 점수를 메긴다. (FR은 반드시 해야 하므로 필요없다)
Negotiation	요구사항의 우선순위 측정은 ranking, ahp, grouping, bubble sort, hundred dollors
Specification	뽑아낸 요구사항을 분류 / 조직화한다.
SRS	Software Requirement Specification (요구사항 최종 산출물). 설계나 Plan이 들어있으면 안된다.
Validation	최종 검증 (프로토타이핑 등)

요구공학 - QA - Functionality

Suitability(적합성)	지정된 작업과 사용자 목적에 따라 적절한 기능들을 제공
Accuracy	올바른 결과를 얼마나 잘 제공할 수 있는가
Interoperability(상호운영성)	다른 시스템과 interaction 할 수 있는 정도
Security	권한이 없는 사람의 접근을 막거나, 데이터의 변조를 막거나, 권한있는 사람이 허용되게 하는 것
Compliance(준수성)	SW 관련된 법적 규제, 관례, 규정을 준수하는 정도

요구공학 - QA - Reliability

Maturity(성숙성)	SW 결함이 발생하여 고장이 나지 않도록 하는 정도
Fault Tolerance(결함허용성)	결함이 발생하여도, 명세한 성능을 유지할 수 있는 정도
Recoverability(복구성)	고장 발생시, 명세된 성능으로 다시 돌아가고 영향받은 데이터를 복구 하는 능력

요구공학 - QA - Usability

Usability	사용자가 쉽게 이해하고 학습하고 사용되고 선호하는 정도
Understandability(이해성)	소프트웨어가 적합한지, 어떻게 사용해야 하는지 사용자가 쉽게 이해하는가?
Learnability(학습성)	사용자가 쉽게 배울 수 있도록 도와주는 능력
Operability(운영성)	사용자가 SW를 쉽게 운영/관리 하게 할 수 있는가?
Attractiveness(선호도)	사용자에 의해 선호되는 정도

요구공학 - QA - Effectivness

Effectiviness	명세된 조건하에서 얼마나 자원을 덜 사용하여 높은 성능을 내는가?
TimeBehavior(시간 반응성)	명세된 조건하에서 처리시간과 처리율이 얼마나 빠르고 좋은가?
Resource Utilization(자원 활용성)	기능을 수행하기 위해서 얼마나 덜 자원을 사용하는가

요구공학 - QA - Maintainability

Analyzability(분석성)	SW 결함의 원인을 진단하는 능력
Changeability(변경성)	명세가 변경되었을때 쉽게 구현하는 정도
Stability(안정성)	SW 변경으로 예상치 않은 결과가 잘 발생하지 않게 하는 정도
Testability	변경된 SW를 검사할 수 있는 능력

요구공학 - QA - Portability

Adaptability(적응성)	SW에서 원래 목적으로 제공되는 것 이외에 다른 환경으로 변경될 수 있는 정도
Installability(설치성)	명세된 환경에 설치가 얼마나 쉬운가
Co-existency(공존성)	공통 자원을 공유해야 하는 환경에 설치될 경우, 다른 SW와 같이 공존하는 정도
Replaceability(대체성)	동일한 환경에서 같은 목적인 SW들과 대체가 얼마나 쉬운가

최적설계 - Viewpoints 4+1

Viewpoints?	시스템을 바라보는 관점. View는 그 관점에서 시스템의 요소를 도식화 한것. Logical Views는 구조를, Process View는 흐름, 즉 런타임 동작을, Development는 개발팀의 산출물 (패키지, 코드 위치등)을, Deployment는 최종 시스템 요소의 물리적인 설치를
Use-Case view	Activity/Info Flow Diagram, UseCase diagram
Logical View	Sequence Diagram, Domain Model Class Diagram
Development view	component diagram, package diagram
Domain Model?	RE 에서 요구사항 분석을 위한 Conceptual class diagram.
Process view	sequence, activity diagram
Physical view	deployment diagram

최적설계 Quality Life cycle

Process Quality
Internal QA	개발팀 내에서 세분화한 QA
External QA	Stake holder 들이 제시한 QA. 위에 2개 모두 제품 관점에서 산정한 모델
Quality in use	사용자 관점에서 산정한 QA의 모델(모음집)
Architecture concerns	요구사항 이외에 아키텍트가 추가로 넣는 요구사항으로, 일반적으로 이 프로젝트에서 추가하는 요구사항 혹은 경험에 따라서 추가하는 요구사항 들이다.

최적설계 - GRASP

Responsibility란?	클래스에 주어진 contract 혹은 의무. 다른 메소드 / 객체와 연계해서 메소드로써 구현됨. 메소드로 동작을 하는 책임도 있는 반면, 다른 객체나 private field를 아는 것도 책임에 포함됨
GRASP	coupling, cohension, expert, controller, creator, don't talk to stranger
Low coupling이 높으면?	재사용이 힘듬. 하나 바꾸면 다 바꿔야 함, 코드 이해가 어려움,
cohension이 낮으면?	여러 책임이 한 클래스에 다 모여있어서 이해가 어려움 직관적이지 않음,
Information Expert	가장 먼저 클래스에 줄 책임은, 가지고 있는 private info (encapsulated)를 관리하고 값을 채워넣는 책임이다.
Creator	A가 B를 매우 친밀하거나, B를 가지고 있거나, B와 aggregate 하거나 B가 생성될때 초기화 정보를 넣어준다면 A가 B를 생성하게 하라.
controller
Don't talk to stranger

최적설계 - ADD 방법론

ADD?	Architecture Design Methodology
Plan do and check	모듈 선택 -> 분해 -> Architecture Driver 선택 -> NFR해결을 위한 Style 선택 + FR을 위한 하위 모듈 실체화 -> 하위 모듈의 인터페이스 정의 -> Usecase, QA를 검증하고 contraint 확정 -> 이하 반복

최적설계 - Unified process

UP 구성	inception phase, elaboration, construction, transition
각 phase 별 disciplines	test, code, planning, Req, analysis & design, business modeling, deployment, configuration & change management, Project management
Inception phase	Business modeling, Req 추출, Prototyping, feasibility study
Elaboration	ADD 방법론 등을 사용하여 아키텍처 설계를 해서 Baseline Architecture를 정의한다. Baseline archirecture는 skeleton architecture로 elaboration 단계가 끝나면 최종 완성되며 이후 절대로 바뀌어서는 안된다.

최적설계 - Pattern, Style, Idium

Architecture Style	== Architecture Pattern
Pattern?	특정한 문맥(조건,상황)에서 발생하는 설계 문제가 있을때 그것을 잘 해결하는 일반화된 설계 형태를 제시한 것.
Design pattern?	components나 subsystem을 설계할 때 적용 가능한 패턴
idium	구현시 적용 가능한 패턴

클래스 관계

Association	클래스를 사용함
Aggregation	포함 관계가 있지만 owner가 죽어도 owning은 영향 없음. 중간에 다른 객체에 붙을 수도 있음
Composition	포함관계가 있으며 라이프 사이클이 동일함.

품질속성

품질속성 시나리오 구성	Source(위치), 원인(Stimulus), 대상(Artifact), 상태(Environment), 대응(Response), 대응결과(Response Measure)
Modifiability	변경 지역화(책임을 분리시킴), 기존 인터페이스를 유지, LateBinding
성능(자원수요)	필요한 자원을 줄이기(알고리즘 개선, 요청 자체를 없앤다, 이벤트 빈도 줄이기,
성능(자원관리)	동시성 제공,데이터 처리가 병목 되지 않도록, 자원을 늘림(HW),
가용성(오류감지)	Ping,Echo(다른 컴포넌트,프로세스가 잘 동작하는지 확인), HeartBeat(정상이라고 신호를 내가 보낸다),
가용성(오류복구)	같은 일을 처리하는 여러개의 프로세스/Node를 둬서 하나가 망가져도 다른쪽이 잘 동작시킴, 롤백
보안	기밀성(권한 있는 사람만 본다), 무결성(권한 있는 사람만 write), 인증(송신자가 맞는지 확인), Non-Repudication(부인봉쇄, 안보냈다고 뻥카치지 못하게, AccessControl(권한이 있어야 사용 가능), 가용성(권한이 있으면 서비스 이용이 지속되야)

UML 표기

class diagram	class, interface, component, visibility
deployment diagram	artifacts(file, db), node, components
component diagram	port, provided interface, required interface, component,
sequence	lifeline, message, interaction use,
activity diagram	swim lanes, merge node, decision node, initial node, final node, merge node, fork node
data flow	external entity, process, datastore

최적설계 - Batch Sequencial

분류	Data Flow
뭐냐	Data Flow AS 중 하나. 데이터가 단방향으로 하나의 서브시스템에서 다른 서브시스템으로 이동한다. 각 서브시스템은 input이 넘어와야만 작업할 수 있다.
참여자	Program, Data Store
장점	오직 데이터(파일)에 의해서만 연결되어있이므로 데이터 포맷만 맞추면 쉽게 분리 가능,
단점	데이터만 input이므로 외부에서 각 서브시스템을 제어하기에는 다소 맞지 않는다. 동시성을 지원하지 못하므로 높은 latency를 가진다.

최적설계 - Pipe and Filter

분류	Data Flow
뭐냐	스트림을 따라서 데이터가 필터에 도착하면 데이터를 가공하고 다음 필터로 파이프로 전달.
참여자	데이터스트림, 필터, 파이프
장점	동시성을 제공한다. 데이터가 끊임없이 밀려오고 각 필터는 자기 담당만 처리하므로., 재사용, 변경이쉽다, 단순하다.
단점	동적으로 데이터의 포맷을 변경할 수 없다.
Batch Sequencial의 차이	사전 처리 과정이 완료되어야 하지만, 파이프&필터는 데이터가 계속 주어지는 상황을 전제로 한것이다.

최적설계 - Process Control

분류	Data Flow
참여자	Controller, Actuator, Process, Sensor
뭐냐	Controller가 현재 상태를 측정값을 보고 Actuator에게 start/stop을 내린다. Actuator는 핵심 기능을 담당하는 Process에게 이 정보를 전달하고 Process에 input이 들어가면 start/stop을 수행한다. 그 결과는 sensor가 수집하여 다시 Controller에게 전달한다. 이처럼 closed - loop의 구조를 주로 띄게 된다.
장점	복잡한 공식이 없어도 상태값을 일정한 수준으로 유지하게 하는게 가능하다.
추천 적용	상태 값을 제어하는 임베디드 시스템, 빌딩 온도 제어 시스템, 핵 발전소 등

최적설계 - Repository

참여자	Repository, Components
뭐냐	중간에 공유 저장소가 있는 것. 그래서 저장소를 기반으로 데이터 interaction 하는 것이다.
장점	데이터 통합되게 해준다, BackUp&Restore를 쉽게 달성한다, 각 components의 확장성/ 재사용 가능하다 (직접적으로 interaction을 하지 않기 때문에),
단점	데이터 중복이 발생할 수 있다, 저장된 데이터의 구조에 components들이 높은 의존성, 데이터의 포맷을 변경하고 확장하는 것은 비용이 크다.

최적설계 - Blackboard

분류	Data Centered
참여자	Blackboard, Control, KnowledgeSource
뭐냐	KnowledgeSource는 독립된 서브시스템으로 복잡한 문제 1개를 잘 알려진방법으로 해결한다. Blackboard는 공유 저장소를 가지고 있고 여기에 붙은 KnowledgeSource들은 blackboard에 있는 데이터를 각각 해결해서 업데이트한다. Control은 이 변화를 모니터링 한다.
언제?	유일한 해결책이 없는 복잡한 문제를 해결해야 할때
장점	KnowledgeSource를 쉽게 추가가 가능하다. 동시성을 제공한다.
단점	blackboard의 구조를 바꾸면 매우 많이 바꿔야 한다. 언제까지 계속 데이터를 업데이트 해야 하는지 판단하는 것이 어렵다. 여러 KnowledgeSource들 간에 동기화문제

최적설계 - Layered

분류	Hierarchical
참여자	Layer
뭐냐	상위 레이어는 하위레이어에 의존한다. 아래에서 위로 의존관계가 맺어지지는 않는다. 하나의 Layer에서 발생한 수정은 다른 layer에 영향을 주지 않는다.
언제 적용?	시스템이 확장해가면서 최소한의 의존을 만들고 각 모듈이 모듈성 재사용성을 높이면서 독립적으로 개발될 수 있어야 할때
장점	인터페이스가 변하지 않는 한, 하위레이어의 수정이 상위레이어에 영향을 주지 않는다, 각 layer는 미리 정의된 인터페이스로 통신하기 때문에 인터페이스만 지켜주면 쉽게 확장/교체 가능하다.,
단점	런타임 성능이 떨어진다. 아래까지 내려갔다가 위로 올라와야 하니까, Exception Handling도 마찬가지로 depth가 깊기 때문이다.

최적설계 - PlugIn Architecture

분류	Hierarchical
참여자	CoreSystem, Plug-in modules
뭐냐	App 추가 로직을 PlugIn을 떼었다가 붙였다가 하는 것. 핵심로직은 coreSystem으로 미리 구현을 해놓아야 한다.
장점	이식성, 확장성,

최적설계 - Virtual Machine

참여자	Application, Virtual Machine, Existing Platform
장점	이식성, SW개발 쉬움
단점	속도 느림

최적설계 - Non-buffered event invoc

분류	Implict asynchronous communication software
참여자	Event source, event listener
뭐냐	버퍼를 두지 않고 컴포넌트 끼리 비동기로 interaction 한다. 이벤트가 발생하면 바로 쏜다. 옵저버 패턴하고 유사함
장점	런타임에 listener를 쉽게 추가/삭제, 재사용성(쉽게 다른 source, listener를 붙일 수 있다),
단점	listener의 동작이 언제 끝날지 알기가 힘들다, 디버깅이 어려움, 버퍼 비동기보다 직접적으로 의존하므로 결합도가 높다

최적설계 - Buffered Message Based

분류	Implicit Asynchronous communication
참여자	MessageBroker, Consumer, Producer
뭐냐	Producer가 msg를 xml 등과 같은 형태로 broker에 넣는다. Broker는 가공하거나, 보안체크를 하거나 다른 borker로 route하거나 consumer들에게 전달한다.
언제 적용	네트워크 관리, 날씨 예보, 뱅킹 시스템
장점	비동기가 가능한데 Producer가 메시지를 보낼때 Consumer가 idle 상태가 아니어도 된다, 매우 독립적인 설계가 가능하며 쉽게 교체/확장이 가능하다, producer는 누가 이 메시지를 받을 것인지 어디에 위치하고 있는지 몰라도 된다, 동시성을 보장한다
단점	메세지 큐에 한계는 있다, 구현에 복잡도가 올라간다, 디버깅이 어렵고 직접호출보다 퍼포먼스가 저하된다.

최적설계 - Client - server

분류	Distributed
참여자	Client, Server
뭐냐	전체 시스템의 구조를 요청자와 처리자로 tier를 분산하는 것이다.
언제?	클라이언트가 여러명이 하나의 서비스로 접근하는데 이를 효율적으로 관리하고 싶을때, 리소스 Control은 중앙집중으로 하고 싶고 리소스 자체는 여러 군데 분산시키고 싶을때
장점	책임을 분리시킬 수 있다. (presentation, businiess logic), 보안성, 서버의 가용성

최적설계 - Multi tier

분류	Distributed
참여자	Tier
Layer vs Tier	Layer는 소프트웨어 적으로 구분한 구조의 구성 요소, Tier는 물리적인 요소
장점	중간에 tier를 넣음으로써 확장성과 재사용성, 비지니스 관련은 중간 티어에만 들어감, 트래픽 감소, 신뢰성 증가,
단점	테스트가 더 어렵다

최적설계 - Dispatcher

분류	Distributed
참여자	Client, Broker, Server
뭐냐	Server들은 모두 같은 구현이다. Broker는 Server의 걸린 load를 보고 제일 좋은 Server로 client의 요청을 연결 시켜 준다. Broker또한 별도의 tier이며, Server는 Broker에 register 한다.
장점	Client-Server가 결합도가 낮다, 트래픽에 강하다, 서비스 가용성이 좋다,
단점	Broker를 거쳐서 통신하므로 퍼포먼스 저하, 테스트가 어렵다.

최적설계 - Broker

분류	distributed
참여자	Broker, Client, Servant
뭐냐	CORBA임. 분산객체 각 Node는 Broker를 앞에 달고 있고 Broker는 해당 Node 내에서 등록한 Servant 들을 모두 들고 있음. Node와 Node는 서로 통신이 가능함.
장점	컴포넌트가 로컬에 있건 외부에 어디에 있건 위치 관계없이 의도한 결과를 얻는다, 완전히 다른 서버와 플랫폼 간의 interaction이 쉽게 가능함, 컴포넌트 재사용이 좋다
단점	성능이 떨어진다, 장애가 발생할 경우 대처가 어렵다 (fault-torelance), 테스트가 어렵다
언제?	많은 시스템이 분산되어있다, 바인딩을 동적으로 바꾸고, 객체로써 다루고 싶고 서비스 제공자의 위치를 알고싶지도 않고....

최적설계 - Master slave

분류	Distributed
참여자	Master, Slave
뭐냐	Master는 Slave 중에서 주어진 문제를 해결할 수 있는 놈을 선정해서 그 결과를 받아옴
장점	fault tolerance, 신뢰성(실패해도 다른 slave와 연결)
언제 적용	fault tolerance, reliability가 중요할때

최적설계 - P2P

분류	Distributed
뭐냐	동일한 역할을 부여받은 Peer 노드 끼리 Provider 이자 Consumer로써 서로 연결되어 하나의 contents에 대한 일정 비율을 각각 나누어 가져서 제공하는 것
structured, unstructured	unstructured는 말그대로 중앙이 아무것도 없음, structured는 중앙에 관리 혹은 분배하는 놈이 더 있고 더 효율적임.
장점	중앙이 없으므로 중앙이 실패할 염려도 없음, 확장성이 좋음 그냥 연결해서 붙이면 끝, 별도의 DB나 서버를 둘 필요가 없음
단점	시스템 전체적으로 일관성을 갖도록 유지하는 것이 어렵다, 각 node 마다 power가 다르다

최적설계 - Service oriented

분류	distributed
뭐냐	서비스(흔히 생각하는 OS의 서비스가 아니다)라고 하는 작은 단위에 독립적인 MVC를 모두 가진 서브시스템이 있다. 이 서비스들을 매우 완화된 포맷인 XML등을 사용해서 레고블럭 처럼 쌓아서 통신하는 것이다. 네트워크를 사용할 수도 있고 사용하지 않을 수도 있다. 다른 언어라고 해도 XML만 지원하면 동작한다.
언제?	하나의 큰 시스템을 책임으로 묶어서 보다 작은 서비스로 만들어, 이들간에 표준화된 인터페이스를 정의하고 이를 잘 블럭처럼 쌓아올려서 다른 시스템을 만들때 재사용하고자 하는 것
장점	상호운용성, 확장성, 재사용성
단점	구축하기 어렵다, 성능이 떨어진다, 병목현상이 발생할 수 있다.

최적설계 - micro service

분류	Distributed
뭐냐	SOA의 일종의 부분집합이다. SOA는 monolithic 아키텍처다. interaction은 언어에서 독립적인 방법으로 수행하지만 공통으로 묶을 수 있는 부분은 묶는다. (예를들면 공용 DB) 반면 Microsoervice는 각 서비스를 작게 쪼개서 네트워크를 통해 API를 제공할 뿐 그 안에 구성은 encapsulation 하듯이 감추는 것이다. DB도 각자사용하거나 DB를 없앤다.
RESTful?	네트워크로 API를 만들려면 다양한 방식이 있을 것이다. json으로 https로 날려도 되고. RESTful은 이러한 API를 HTTP의 방식 GET, POST 등을 사용해서 표현하는 것을 말한다. 즉 API 정의방법.
장점	독립적인 작은 서비스이므로 확장이 쉽고, 결합도가 낮다. 모듈화 수준이 높다, 테스트/개발이 쉽다.
단점
언제?	결합도가 너무너무 높다, 하나만 기능을 고치려는데 시스템 전체를 다 체크한다, 기존 시스템을 분해하면 수십개의 micro service가 나온다.

최적설계 - MVC

단점	View와 Control 구분하는 것이 때로는 명확하지 않다, Model이 변경되면 impact가 크다.