소프트웨어 아키텍처

소프트웨어 아키텍처란?

• 한 소프트웨어의 뼈대 또는 고수준의 기반의 디자인을 의미
• 공통된 부분은 모듈화를 통해 재사용성과 유지보수의 편의성을 높이는 방식

디자인 패턴

소프트웨어 아키텍처와는 달리 디자인 패턴은 뼈대나 기반이 아닌 코드 수준의 디자인을 담당하며, 각각의 모듈이 담당하는 역할, 클래스의 범위, 함수의 목적 등을 디자인한다

모듈화

• 확장성 : 서비스 규모가 커질수록 확장성을 고려하지 않은 코드는 코드 수정에 많은 시간 소모
• 재사용성 : 반복되는 로직은 함수 또는 모듈로 분리화하여 차후 호출하여 재사용 가능
• 유지보수 편의성 : 여러 로직이 뒤엉킨 코드는 유지보수가 어렵다
• 가독성 : 개발은 혼자하는 것이 아니라 팀 단위로 이뤄지기에 남들도 이해하기 쉬운 코드가 좋은 코드
• 테스트 가능성 : 역할에 따라 분리된 코드는 테스트하기 쉬워진다

MVC Pattern 이란?

• 뷰, 즉 유저 인터페이스와 비즈니스 로직을 구분하는데 중점을 두는 아키텍처 패턴
• MVC Pattern도 웹 개발 역사의 흐름에 따라 변화
• 기존에는 서버 사이드에서 한번에 다뤄지던 구조로 View가 Model에 의존하던 방식
  • JSP(HTML + Java)를 위한 MVC 패턴
• 현재는 SPA 방식과 클라이언트 사이드 렌더링이 발전함에 따라 View(Frontend)와 비즈니스 로직을 다루는 Model(Backend)이 완벽히 분리
  • Apple에서 나온 Cocoa MVC를 기반
• 완벽히 관심사에 따라 분리된 View와 Model을 중간 요소인 Controller가 중재

구조

• Model : 유저 인터페이스로부터 독립적이며, 데이터베이스에 접근하여 데이터를 조작하고 비즈니스 로직을 수행하여 결과물을 반환하는 역할
  • 자기 자신이 하는 Task만 인지하며, 다른 계층의 역할은 모름
• View : 유저에게 데이터를 보여주는 User Interface 역할
  • 로직보다는 데이터를 반영하여 화면에 보여주는 역할에 충실
• Controller : Model과 View를 이어주며 사용자의 요청을 받아 해석하고 처리하는 역할

동작 플로우

1. 사용자의 동작을 수행하기 위한 요청이 Controller로 전달
2. Controller에서 요청을 정제하여 Model에게 필요한 데이터 요청
3. Model은 Database에 접근하고 필요한 데이터를 찾아 Controller에게 전달
4. Controller는 Model에게 전달 받은 데이터를 나타내 줄 View를 선택하여 데이터 전달
5. View는 사용자가 보는 UI에 Controller로부터 받은 데이터를 반영하여 변경된 화면 출력

장점

• 관심사에 따른 염려의 분리에 따라 각 계층의 독립성이 증가
  • 단일책임원칙
• 독립적인 모듈들의 재사용성 증가
• 개발 확장성 증가
• 3개의 계층으로 역할이 나눠져 있어 협업시 역할 분담에 용이
• 테스트 주도 개발
  • 각각의 계층에 속한 각각의 모듈들을 테스트하기 편하다

단점

• 초반 관심사의 분리를 위한 설계 시간 추가 소요
• 프로젝트 규모가 커질수록 백엔드에서 데이터 흐름을 제어하는 Controller와 비즈니스 로직과 데이터베이스 조작을 담당하는 Model의 비중이 너무 커지고 코드의 복잡성이 올라간다
  • 각 계층의 비중을 낮춰줄 추가 계층 필요

MVP Pattern 이란?

• 뷰가 최대한의 로직을 배제하고 본연의 임무인 화면 표시에 집중하게끔 Controller 대신 Presenter라는 새로운 컴포넌트를 통해 옛날 MVC 패턴의 문제였던 Model과 View에 대한 결합도를 낮춘 아키텍처 패턴

구조

• Model : 유저 인터페이스로부터 독립적이며, 데이터베이스에 접근하여 데이터를 조작하고 비즈니스 로직을 수행하여 결과물을 반환하는 역할
  • 자기 자신이 하는 Task만 인지하며, 다른 계층의 역할은 모름
• View : 유저에게 데이터를 보여주는 User Interface 역할
  • 자기 자신이 하는 Task만 인지하며, 다른 계층의 역할은 모름
• Presenter : View로부터 오는 HTTP 요청을 받아 Model에게 필요한 Task를 맡기고, View에 결과를 전달하는 역할을 하여 View와 Model의 접착제 역할을 담당
  • Model과 View를 잇는 중간 다리 역할
  • Model과 View의 Task 인지
  • Presenter 와 View는 1:1 관계

동작 플로우

1. View로부터 사용자의 동작을 수행하기 위한 모든 요청이 Presenter로 전달
2. Presenter에서 View로부터 HTTP 요청을 받아 Model에게 전달하기 쉽게 가공하여 Model에게 필요한 Task 명령
3. Model에서 해당 Task를 Database 조작을 통해 처리하고 결과물을 Presenter에게 전달
4. Presenter는 전달받은 결과물을 가공하여 View에게 응답
5. View는 전달받은 결과물을 바탕으로 화면 Update

장점

• Model과 View 사이의 의존도가 감소
• 관심사에 따른 염려의 분리
  • 데이터 관련 로직은 Model, 유저 인터페이스는 View, Model과 View를 연결하며 Model에 접근할 수 있는 유일한 대상인 Presenter
• 동시적인 개발
  • 3개의 계층으로 역할이 나눠져 있어 역할 분담에 용이하고 협업 가능한 프로젝트를 구성할 수 있다
• 수정의 용이함
  • 다른 계층에 영향을 주지 않고 문제가 발생한 계층의 로직을 찾아 문제 해결 가능
• 테스트 주도 개발
  • 각각의 레이어에 속한 각각의 모듈들을 테스트하기 편하다

단점

• MVC 패턴 때보다 Controller 역할의 확장 버전인 Presenter의 임무가 막중해지면서 의존도 상승
• Presenter와 View가 1:1 관계이기에 프로젝트 규모가 커질수록 코드가 기하급수적으로 증가

MVVM Pattern 이란?

구조

• Model : 데이터베이스에 접근하여 데이터를 조작하는 역할
  • 자기 자신이 하는 Task만 인지하며, 다른 계층의 역할은 모름
• View : 유저에게 데이터를 보여주는 User Interface 역할
  • 자기 자신이 하는 Task만 인지하며, 다른 계층의 역할은 모름
• View Model : View를 나타내기 위한 Model이며, View를 위한 데이터 처리를 하는 역할
  • View Model과 View는 1:N 관계

동작 플로우

1. View로부터 사용자의 동작을 수행하기 위한 요청이 Command 패턴으로 View Model에게 전달
2. View Model에서 Model에게 데이터 요청
3. Model에서 해당 Task를 Database 조작을 통해 처리하고 결과물을 Presenter에게 전달
4. Presenter는 전달받은 결과물을 가공하여 View에게 응답
5. View는 View Model과 Data Binding을 통해 화면 Update

장점

• View와 Model 사이의 의존성이 없다
• Command 패턴과 Data Binding으로 View와 View Model 사이의 의존성 또한 없다

단점

• View Model 설계의 어려움