Architecture Style 비교

Style	Situation	Component	Pros	Cons	Example
Main-Subroutine		Main Subroutines in multiple layers	Reusability
Layered	관련있는 역할을 가진 클래스들을 모아 계층적인 component 구조로 배치할 수 있는 경우. 각 layer는 독립적인 역할을 가지며 이웃한 layer들 간에 서로 interaction할 수 있음. 상위 layer는 하위 layer에 request를 하며 하위 layer는 상위 layer에 response를 줌.	layers 주로 Presentation layer Business layer Persistance layer Database layer로 구성	Layer별 interface가 먼저 정의된다면 각 layer별로 점진적이고 독립적인 개발이 가능함. 상위 layer의 하위 layer로 부터의 독립성이 높음. 이식성이 높음.	상하위의 layer간 통신만 가능한 구조로 인해 여러 layer를 거치는 통신이 비번한 경우, performance가 낮아질 수 있음. 혹은 하위 layer에서의 오류가 상위 layer들로 전달되어 문제을 야기할 수 있음.	Android Framework OSI 7 layer
Virtual Machine	여러 HW 혹은 OS를 가상화하여 특정 프로그래밍 언어나 특정 어플리케이션 수행 환경을 가상으로 제공함.		HW, OS 혹은 Platform에 독립적인 환경을 제공하여 Portability가 높아짐. 다양한 환경에서 수행되어야 하는 SW의 개발 용이성을 제공함.	Interpreter의 수행으로 실행 속도가 낮음.	Interpreter JVM
Non-buffered Event-Based Implicit Invocations		Event source Event listener	새로운 event handler (event listener)를 추가하기 용이함. 동적인 등록 절차를 통해 event source와 listener가 연결되므로 event source와 listener가 runtime에 변경되기 용이함.	Event listener의 동작이 언제 끝날지 예상되지 않아 테스트와 디버깅이 어려움. Buffered 방식 보다는 event source와 listener가 더 tightly coupled 되어 있음.
Buffered Message-Based	분산된 Component간에 독립성의 높이면서 asynchronouse한 통신 방법이 필요한 경우. Distributed transactional business application에서 많이 사용됨.	Message producers Message consumers Message service provider	message producer와 consumer가 message format만 공유하고 상대방을 알지 않아도 되므로 anonymity (익명성)이 높음. message producer와 consumer이 직접 통신하는 것이 아니므로 concurrency를 제공함. Acknowledgement, priority, control level 등을 통해 메시지 전달 방식을 여러가지로 조정할 수 있어 메시지 전달의 scalability와 reliability를 높일 수 있음.	구현과 테스팅, 디버깅이 어려움.	Publisher-Subscriber
Client-Server	전체 시스템의 기능이 요청하는 역할(Client)와 요청을 처리하는 역할(Server)로 나뉘는 경우.	Client Server	분산 환경에서 UI presentation와 business logic의 분리에 용이함. Server의 reusability가 높음.	요구 사항 변경시 client/server 양단을 변경해야하는 번거로움이 있음. Server의 가용성, 안정성을 유지하는데 어려움이 있음. Server/Client가 분산되어 있어 보다 복잡하고 어려운 보안 이슈가 발생할 수 있음.
Multi-tiers	분산 환경에서 presentation, business logic, database component가 나뉘어 지는 경우. Enterprise application에서 주로 사용됨.	Front-end tier for presentation Middle-tier for business logic and execution Back-end tier for database	middle-tier가 추가됨으로써 reusability와 scalability가 증대됨. Business logic의 변경이 middle-tier에만 국한됨.	Client-Server대비 tier의 수가 많아짐에 따라 test가 더 어려워짐.
Proxy	원격에 있는 객체에 대한 method call을 transparent하게 제공하려고 할 때. 긴 operation을 가진 method를 짧게 바로 끝난 것처럼 보이게 할 때. 서비스 제공 객체에 대한 access control을 제공하고자 할 때.	Service object Service Proxy object			RPC
Dispatcher (Load Balancer)	분산 환경에서 scalability와 availability를 높이기 위해서 여러대의 서버를 사용하면서 client에게는 한 대의 서버로 보이게 할 때. Load balancing		서비스의 availability가 높아짐. Scalability가 높아짐.
Service-oriented (SOA)	Client가 Service directory를 통해 필요한 service를 찾은 후 이 서비스에 request를 보내고 받는 방법. 전체 business sequence나 logic을 명세하기 위해서 Orchestration language가 추가로 필요함.	Client Service Directory Services	작은 단위의 각각의 서비스가 독립적으로 개발되고 수행됨. 서비스의 복합적인 구성이 용이하여 개별 서비스의 reusability가 높고 business application의 개발이 효율적임.개별의 서비스		Web Services
Pipe and Filter	시스템이 여러 단계의 데이터 프로세싱 스텝으로 나뉘는 경우.	Data Source Filter: 데이터를 변경하거나 프로세싱하는 각 단계를 캡슐화하고 있음. (active/passige) Pipe Data Sink Data Stream	Concurrency: High throughput Reusability: 단계별 프로세싱이 filter로 filter를 변경함으로써encapsulation되어 끼워넣거나 치환하기가 쉽다. Modifiability: pipe를 통한 filter간 연결로 filter간 low coupling이 형성되어 새로운 filter를 추가할 때 다른 filter에 주는 영향이 적다. Flexibility: Sequential execution과 parallel execution 두가지를 지원함.	Interaction이 많은 경우에 적합하지 않음. Pip를 통과할 때마다 data parsing에 대한 overhead가 늘어남. Dynamic하게 구성하기 어려움.	Named pipe in Unix
Repository	여러 component가 많은 양의 데이터를 계속 주고 받아야할 경우. 데이터 저장소를 통한 통신 방법.	Agents Repository	데이터 저장소를 통해서만 다른 component와 통신하므로 새로운 component를 추가하기가 용이하다.	Data store의 안정성/가용성이 아주 중요하여 centralized repository의 경우, 쉽게 장애가 발생할 수 있다. Data 구조가 자주 변경되는 경우 agent에 주는 영향이 크다.
MVC	데이터에 의해 변경되기 쉬운 UI를 가진 App인 경우.	Model: 모든 fuctional service를 제공하고 데이터를 encapsulation함. View : 데이터를 display하고 데이터가 변경될 때마다 업데이트하는 역할. Control : User input request를 관리하고 user interaction sequence를 control하고 output display를 위한 view를 선정하고 그 밖의 모든 작업들을 하는 역할.	같은 데이터 모델로 여러 View가 Sync될 수 있음. Modifiability: View를 변경하거나 새로운 View를 추가하기 쉬움. (예를 들어 새로운 View기술을 도입하기 쉬움) Graphics, Programming, DB 개발자가 한 팀에서 함께 일하는 경우, 효율적임.	Data model이 변경되는 경우에는 변경 노력이 비쌈. View와 Controller의 구분이 명확하지 않은 경우가 있음.