❓Software Architecture
소프트웨어 아키텍처는 모든 소프트웨어 시스템의 기본 구조를 말하며 시스템이 제대로 기능하고 작동하도록 하는 모든 측면을 말한다.
소프트웨어 시스템에서의 아키텍처는 물리적 설계가 아닌 구성 요소의 설계, 구성 요소 간의 관계, 사용자 상호 작용 및 시스템에 대한 사용자의 요구를 포함한다.
예로써는 Microservices, client-server, layered architecture 등의 구조들이 있다.
그렇다면 Layered Architecture는 무엇일까?
❓Layered Architecture
소프트웨어 개발에서 일반적으로 가장 많이 사용되는 아키텍처이다. Layer의 수에 따라 N Layered Architecture라고 불려지는데 단일 소프트웨어 단위로 함께 기능하는 여러 개별 수평 Layer로 구성된 아키텍처 패턴이다. 즉, 각 Layer은 애플리케이션 내에서의 특정 역할과 관심사 별로 구분되는 것이다.
관련되거나 유사한 구성요소들은 같은 Layer에 배치된다.
주요한 특징은 Layer1에서 Layer3에 접근하기 위해선 Layer2를 통해야한다는 것이다. 즉, 바로 아래 레이어로만 접근이 가능하다는 것이다. 또 다른 특징은 위에서 말했던 관심사의 분리를 통한 격리 Layer라는 특징인데 이는 하나의 Layer의 변경 사항은 변경된 특정 레이어로 격리된다는 것이다. 즉, 종속성을 저하시킨다.
응용 프로그램의 크기와 복잡성에 따라 3~5개 이상의 레이어로 구분된 구조들을 사용한다.
그 중 MVC 패턴을 이용한 3 Layered Architecture에 대해서 알아보자.
❓3 Layered Architecture
3 Layered Architecture는 애플리케이션을 3개의 논리적 컴퓨팅 계층으로 구성하는 소프트웨어 애플리케이션이다. 2 Layered Architecture를 극복하기 위해 탄생했고 사용자 인터페이스 환경과 데이터 베이스 관리 환경 사이의 중간층이 추가된 구조이다.
중간층인 Application Layer에서는 트랜잭션 처리/모니터, 메시지 서버, 응용 서버 등 다양한 방법으로 구축될 수 있다.
각 Layer가 어떤 관심사를 가지고 있는지 알아보자.
1. Presentation Layer
소프트웨어 시스템과 사용자 상호 작용을 담당한다. 주요 목적은 정보를 표시하고 사용자로부터 정보를 수집하는 것이다. 사용자 데이터를 가져와서 Application Layer로 전달하여 처리하는데 사용된다.
예를 들어 웹 브라우저, 데스크탑 애플리케이션 또는 GUI에서 실행될 수 있다.
2. Service Layer
기능 요구 사항 달성과 관련된 측면을 처리한다. Presentation Layer에서 수집된 정보를 비즈니스 로직을 사용하여 처리하는데 때로는 Data Access Layer의 다른 정보들과 비교해서 처리한다. (애플리케이션의 모든 비즈니스 로직에 따라 데이터를 처리함.) 또 Data Access Layer의 데이터를 추가, 삭제 또는 수정할 수 있다.
⇒ Business Layer라고 나와있지만 Service Layer라고 적는 것이 더 이해가 잘된다고 생각한다.
애플리케이션의 구동을 위해서 필요한 로직들 중에는 비즈니스 로직과 비즈니스 로직이 아닌 로직이 존재한다. 무슨 말일까?
이를 이해하기 위해선 비즈니스 로직이란 무엇일까부터 고민해봐야한다.
비즈니스 로직이란 비즈니스적인 의미를 가진 로직을 의미한다. 예를들면, 재고가 있는 상품의 주문이 가능하다던가 혹은 배송중인 상품의 주문을 취소할 수 없는 것과 같은 로직이다. 이러한 로직은 ‘핵심적인 로직’이다.
그렇다면 비즈니스 로직이 아닌 로직은 무엇일까? 말 그대로 비지니스적인 의미를 가지지 않은 로직이다. 예를 들면 사용자 인증 로직, 로깅 로직, 트랜잭션 로직과 같은 로직을 의미한다. 이는 비즈니스적 의미를 가지진 않았지만 서비스의 구동 및 유지를 위해선 ‘필수적인 로직’이다.
이 두 가지 로직이 배치된 곳이 Service Layer이다. Business Layer라는 혼동이 올 수 있다고 생각한다.
여기서 서비스가 커진다면 어떨까?
Service Layer 내에서도 비즈니스 로직이 이쪽 저쪽 중복으로 작성이 되고 비즈니스 로직과 비즈니스 로직이 아닌 로직을 구분하기 점점 어려워질 것이다. 그러다 보면 비즈니스 로직을 고치는 경우 비즈니스 로직이 아닌 로직도 고쳐야하는 경우가 생길 것이다. 굉장히 불편하다. ⇒ 그래서 Layer를 하나 더 나눈 4 Tier 아키텍처 ( Presentation - Service - Domain - InfraStructure )가 생겼을 것이다. (이는 DDD (Domain Driven Design) 같은 곳에서 사용한다고 한다. )
Business Layer에서 Business는 필자에게는 큰 혼란이었다. MVC 패턴에서 Model은 데이터와 비즈니스 로직을 관리하는데 그렇다면 Model == Business Layer 인 것인가? 이에 대해 생각하고 또 다른 지식들이 섞이다가 현재 참가중인 교육 (프로그래머스 데브코스) 멘토님께 여쭤보고 정확한 이해와 혼란을 잡을 수 있었다. (감사합니다,,,ㅠㅠ)
3. Data Access Layer
데이터베이스와 그것에 액세스해서 읽거나 쓰는 것을 관리하는 프로그램을 포함한다. Application이 처리하는 모든 정보를 저장한다.
❓MVC 패턴
소프트웨어 디자인 패턴이고 사용자 인터페이스로부터 비즈니스 로직을 분리하여 애플리케이션의 시각적 요소나 비즈니스 로직을 서로 영향 없이 쉽게 고칠 수 있는 애플리케이션을 만들기 위한 소프트웨어 디자인 패턴이다.
즉, 유지보수가 편해지는 코드 구성 방식이다.
MVC 각각이 무엇을 의미하고 역할은 뭔지에 대해서 알아보자.
1. Model
- 데이터와 비즈니스 로직을 관리한다. ⇒ 데이터와 관련된 부분
- View, Controller에 대한 의존을 가지지 않는다.
2. View
- Model의 데이터를 사용해 시각적인 화면을 구성하는 역할이다. ⇒ 사용자에게 보여지는 부분
- Model과 의존성을 가질수도 있고 안가질수도 있다.
- Controller에는 의존성을 가지면 안된다.
3. Controller
- 사용자의 입력을 받아서 처리하는 역할
- Model을 변경하고 View를 갱신 ⇒ Model과 View를 이어주는 부분
⇒ 해당 패턴을 활용하는 방법은 아래 영상을 참고하자.
MVC와 Layered Architecture가 어떤 관계가 있길래 여기에서 설명을 하는 것일까?
필자는 MVC와 Layered Architecture의 차이점을 몰랐고 둘이 같거나 비슷한 개념이라고 생각했다.
하지만 이 둘은 같지 않다. ⇒ 차이점에 대해서 알아보자.
Layered Architecture와 MVC의 차이점
Layered Architecture는 관심사를 분리해서 Layer들로 나누고 Layer 내부에 관련되거나 유사한 구성요소들을 배치함으로써 Layer간의 종속성을 저하시켜 Layer의 격리를 통한 이점을 만들어내는 Architecture이다.
Layer의 내부의 구성 요소가 되는 것이 MVC 패턴이다. 위에서 설명한 3 Layered Architecture에 대한 내용과 MVC 패턴에 대한 내용을 보고 생각해보면 MVC는 각각 어떤 Layer에 속할까? 아래의 그림과 같은 형태일 것이다.
Model은 데이터와 관련된 부분이다. 데이터와 비즈니스 로직을 관리한다. 그렇다면 비즈니스 로직에 맞춰서 데이터를 처리하는 Business(Domain) Layer에 속할 것이다.
View는 사용자에게 보여지는 부분이다. 그렇기에 사용자와의 상호작용을 통해서 정보를 표시해주고 정보를 가져오는 Presentation Layer에 속할 것이다.
Controller는 사용자의 입력된 Domain을 DTO로 변환하는 등의 처리하고 Model과 View를 이어줘야 하기 때문에 Presentation Layer에 속할 것이다.
Layered Architecture의 장단점
그럼 다시 Layered Architecture로 돌아와서 장단점에 대해서 알아보자.
장점
- 관심사의 분리 - 각 개별 구성 요소의 단일 책임을 보장. ( 종속성 저하 )
- 개발하기 쉬움 - 잘 알려져있고 구현하기 복잡한 패턴이 아니다. 대부분의 애플리케이션, 프로젝트에서 구현할 아키텍처 패턴이 확실치 않은 경우 좋은 출발점이다.
- 테스트가 쉬움 - 모든 Layer가 개별적으로 단위 테스트로 커버될 수 있고 특정 Layer에 속한 구성요소도 분리되어 있어 개별적 테스트가 가능하다.
- 격리 - 각 Layer가 다른 Layer와 독립적이어서 변경 사항이 다른 Layer로 영향을 끼치지 않는다.
단점
- 확장성 - 애플리케이션 복잡도가 증가하고 프로젝트에 더 많은 기능을 추가해야하는 경우 확장하는데 비용이 크다. (모놀리식 구현 경향)
- 상호 의존성 - 하나의 계층이 데이터 수신을 위해선 상위 Layer에 의존하기에 상호 의존성이 존재한다.
- 배포 - 특정 Layer에 대한 변경은 전체 시스템을 재배포해야 함을 의미한다. ( 큰 Application의 경우 더 문제가 된다. )
- 성능 - 비즈니스 요청을 이행하기 위해 Architecture의 여러 Layer를 거쳐야 하는 비효율성으로 인해 고성능 Appication에 적합하지 않음. (병렬처리가 불가능)
Layer vs Tier (차이점을 잘 모른다면 읽어보기)
Layer vs Tier (차이점을 잘 모른다면 읽어보기)
앞선 내용에 대해 표기를 할 때, Tier라는 단어가 한번도 쓰이지 않았다.
필자는 이 둘의 차이점을 몰랐는데 Layered Architecture에 대해서 알아보면서 알게 되었다.
두 단어는 다른 의미이다. 이를 아래의 그림은 이를 잘 표현했다고 생각한다.
왼쪽 그림은 Tier를 나타내는 그림이고 오른쪽 그림은 Layer를 나타내는 그림이다.
그림에서 볼 수 있듯이 Tier는 각 Tier들이 다른 위치에 있는 것을 확인할 수 있고 Layer는 같은 위치에 있는 것을 볼 수 있다.
즉, Tier는 물리적 분리를 의미하고 Layer는 논리적 분리를 의미한다.
Reference
- Layered Architecture에 관한 내용
https://cristinagupca.com/2019/12/04/layered-architecture/
https://umbum.dev/1066
- MVC 패턴에 관한 내용
https://velog.io/@jhp1115/MVC-%ED%8C%A8%ED%84%B4-feat-%EC%9A%B0%EC%95%84%ED%95%9C%ED%85%8C%EC%BD%94%ED%86%A1
https://velog.io/@jhp1115/3-tier-Layered-Architecture%EC%99%80-MVC
- Layer vs Tier에 관한 내용
https://stackoverflow.com/questions/120438/whats-the-difference-between-layers-and-tiers
Uploaded by N2T