Software Architecture Designs
유명하고 많이 사용되고 있는 4가지 소프트웨어 설계에 대해 소개합니다.
배경지식
소프트웨어 아키텍쳐란
소프트웨어 아키텍처 는 소프트웨어 시스템의 기본 구조 및 이러한 구조와 시스템을 만드는 원칙을 말합니다. 각 구조는 소프트웨어 요소, 이들 간의 관계 및 요소와 관계의 속성으로 구성됩니다. 소프트웨어 시스템의 아키텍처는 건물의 아키텍쳐와 유사합니다. 소프트웨어 아키텍쳐는 시스템과 개발 프로젝트에서 개발을 진행할 때 큰 그림 차원에서 가이드 역할을 하기 때문에 매우 중요합니다. 여기서는 유명하고 많이 사용되고 있는 4가지 소프트웨어 설계에 대해 소개합니다.
Layered Architecture

핵심 용어
레이어 간의 격리 (The layers of isolation)
- 다른 레이어의 구성 요소에 영향을 주거나 영향을 미치지 않습니다. 예를 들어 Presentation layer는 Business layer 에 영향을 주지 않도록 설계합니다.
 
구성요소
| Name | Role | 
|---|---|
| Presentation layer | UI 와 API 와 같은 사용자 요청에 대한 관심사를 처리 합니다. | 
| Business layer | 요청에서 비즈니스 로직에 대한 처리를 담당합니다. | 
| Persistence layer | Database 레이어로 저장과 로드를 하는 로직을 포함합니다. | 
| Database layer | 실제 DB와의 연결을 담당합니다. | 

아키텍쳐 분석
| Name | Rating | Why | 
|---|---|---|
| 전반적인 민첩성 | 낮음 | Monolithic 환경 | 
| 배포의 난이도 | 쉬움 | Monolithic 환경 | 
| 테스트 난이도 | 쉬움 | 다른 Layer 는 Mocking 하기 쉬움 | 
| 성능 (Performance) | 낮음 | 여러 Layer 를 거쳐야 함 | 
| 확장성 (Scalability) | 낮음 | Monolithic 환경 | 
| 개발 난이도 | 쉬움 | 많이 사용하는 설계이며 구현하기 쉬움 | 
Event-Driven Architecture

핵심 용어
- 이벤트 중재자 (Event mediator)
 - Distributed asynchronous architecture pattern
 - 높은 확장성
 
구성요소
| Name | Role | 
|---|---|
| 이벤트 큐 | 이벤트 중재자에게 이벤트를 전달 | 
| 중재자 | 이벤트를 받아서 분배 | 
| 이벤트 채널 | 이벤트 중재자에게 이벤트를 전달 받음 | 
| 이벤트 프로세서 | 받은 이벤트에 대한 비즈니스 로직을 수행 | 
아키텍쳐 분석
| Name | Rating | Files | Why | 
|---|---|---|---|
| 전반적인 민첩성 | 높음 | 분리된 이벤트 프로세서 | |
| 배포의 난이도 | 쉬움 | 분리된 이벤트 프로세서 | |
| 테스트 난이도 | 쉬움 | 비동기 환경 | |
| 성능 (Performance) | 높음 | 비동기 환경 | |
| 확장성 (Scalability) | 높음 | 분리된 이벤트 프로세서 | |
| 개발 난이도 | 어려움 | 이벤트 프로세서가 응답하지 않거나 이벤트 중재자에서 발생하는 이슈를 처리하기 어려움 | 
Microkernel Architecture

핵심 용어
- 플러그인 - 독립적
 - Core system 이라는 중심 제품 기반의 설계
 - Core system 은 Plug-in 을 어디서 그리고 어떻게 구할수 있는지 알아야 함
 
예시
- 인터넷 브라우저
 - 통합 개발 환경(IDE)
 
아키텍쳐 분석
| Name | Rating | Why | 
|---|---|---|
| 전반적인 민첩성 | 높음 | 독립된 플러그인 모듈들 | 
| 배포의 난이도 | 높음 | 플러그인이 동적으로 추가 될 수 있음 | 
| 테스트 난이도 | 쉬움 | 독립된 환경 | 
| 성능 (Performance) | 높음 | 독립된 환경 | 
| 확장성 (Scalability) | 낮음 | Core system 은 하나만 존재 | 
| 개발 난이도 | 어려움 | Contract 버전 관리, 플러그인 저장소 | 
Microservices Architecture

핵심 용어
- 하나의 목적을 위한 애플리케이션 단위로 관리
    
- 너무 커지거나 작지 않도록 적합한 수준으로 애플리케이션을 나눠서 설계하는 것이 가장 큰 과제
 
 - Layered 설계 + Service 중심 설계
 - 의존성과 오케스트레이션을 피할 것
 - 하나의 기능이 여러 서비스의 Component 에 걸쳐서 개발할 경우 부적합
 
아키텍쳐 분석
| Name | Rating | Why | 
|---|---|---|
| 전반적인 민첩성 | 높음 | 분리 단위 환경 | 
| 배포의 난이도 | 어려움 | 동시 배포 불가로 인해 한번의 배포에 다른 서비스에 끼칠 영향을 고려해야함 | 
| 테스트 난이도 | 쉬움 | 독립된 환경 (Layered Architecture) | 
| 성능 (Performance) | 낮음 | 분산 환경 | 
| 확장성 (Scalability) | 높음 | 분산 환경 | 
| 개발 난이도 | 쉬움 | 작고 독립된 개발 범위 | 
댓글남기기