스프링&웹 | 기초 지식 2 - 웹 애플리케이션 아키텍처

애플리케이션 아키텍처

 

Def : 애플리케이션 전체의 구조.. 공통된 매커니즘..

ex) 사용자 인터페이스 구조, DB접근방식, 시스템 기반 부분

cf) 스프링이 왜 웹 애플리케이션 개발에 필요한지 이해하기 위한 필수 기초지식

 

아키텍처 설계에는 두가지 목표설정이 반드시 필요

ⓐ 사용자의 요구를 만족시키자는 목표

- use case를 잘 규정하기

ⓑ 개발자나 운영자를 위한 목표 <= 지금은 이것에 집중하며 공부함

- 개발효율 : 의도파악/이해/테스트 쉬운 구조

- 유연성 : 유지보수 쉬운 구조

 

 

.

.

 

앗 그러면 "개발자를 위한 설계 목표"를 충족하기 위해서

웹 애플리케이션의 아키텍처를 구체적으로 어떤 구조, 어떤 기술, 어떻게 설계해야할지 공부해야 한다.

 

 

---

 

웹 애플리케이션 아키텍처

티어(물리층)와 레이어(논리층)

 

 

* 참고 : 클라이언트가 스마트폰이고, 스마트폰 앱이 웹 애플리케이션의 기능 일부를 구현할 경우 레이어의 일부가 클라이언트에 있다고 생각하면 된다. 일반적으로는 "웹 애플리케이션"을 논리적으로 분류한 것이 레이어다. 

* 참고 : 3-tier을 나누는 말은 다양하지만 이쯤 하고 넘어가자. 각 Tier에서 하는 역할을 알면 다 알아들을 것 같다.

 

 

ㅡ 웹 애플리케이션의 레어어를 분류하는 방법

* 분류 방법은 다양하지만 크게 3계층 아키텍처로 보자.

▶ 프레젠테이션 층 :

UI와 Controller 제공

이 층에 배치되는 클래스 : 이름에 Controller나 Action이 붙은 클래스

* 컨트롤러 : 화면 전환 or 화면에서 버튼을 눌렀을 때의 동작 제어 or 세션 관리 등을 함

▶ 비즈니스로직 층 :

비즈니스 로직 제공

이 층에 배치되는 클래스 : 클래스 이름에 업무대상의 이름(=도메인) 또는 use case(=서비스)를 제어하는 클래스

예를들면 Company, Employee, Order (업무) 혹은 XXXService와 같은 use case를 작성한 클래스

▶ 데이터액세스 층

DB 액세스를 추상화

이 층에 배치되는 클래스 : 이름 끝에 Dao가 붙은 클래스

*Data Access Object(Dao)

 

크게 구조를 보면 이렇다.

- 비즈니스 로직 부분 (비즈니스로직층)

- 비즈니스 로직 결과 구현부분 (프레젠테이션&데이터액세스층)

EX: 브라우저에 표시하기, RDB에 저장하는 기술

비즈니스 로직 부분은 어떠한 변경에도 영향받지 않아야 한다.

 

 

ㅡ 웹 애플리케이션 레이어의 개념

로직의 결과 구현이 비즈니스로직에 영향을 미치지 않는 것이 좋은 설계다. 

비즈니스로직은 시스템의 핵심, 기반이므로, 표시 또는 영속화 매커니즘이 변경되어도 아무 상관 없어야 한다.

 

 

ㅡ 오목형 레이어

: 안정의존원칙, 의존관계역전원칙을 만족하는 튼튼한 구조다.

ㅡㅡ 안정 의존 원칙, 의존 관계 역전 원칙

안정 : 다른 패키지 변경이 영향을 주지X

안정 의존 : 안정된 방향으로 의존하라

의존 관계 역전 원칙 : 의존 방향성을 바꾸기 위한 원칙이다.

                              다른 패키지에 큰 영향을 주는 패키지의 의존방향성을 바꿔야 한다.

 

오목형 레이어는 이러한 두가지 원칙을 기초로 한다.

∨ 안정되어야 하는 층 : 비즈니스로직 층

∨ 다른 레이어에 큰 영향을 주는 위치 : 데이터 액세스 층

=> 데이터 액세스 층 & 비즈니스 로직 층의 의존관계를 역전하면

=> 비즈니스 로직 층이 데이터 액세스 층의 인터페이스를 소유하게 된다.

※ 중요한 쪽이 인터페이스를 소유한다는 원칙도 존재 (추후 부품화에서 배우겠다)

 원칙

안정 의존 원칙

 

의존의 역전

상세 설계&구현은 스프링에 의존하는 부분이 많다 (나중에 학습)

 

if 프레젠테이션 층 이용 기술 변경 (브라우저 사용 -> 스마트폰 사용)

if 데이터 액세스 층의 기술 변경 (RDB -> NoSQL)

=> 비즈니스로직 층은 영향을 받지 않는다!

 

※ 비즈니스 층을 다른 층과 분리 :

레이어의 형식적 분류 뿐 아니라, 인터페이스를 통한 약한결합 설계 등 또한 필요

 

※ 레이어는 단방향 액세스다 (서로 인접한 레이어끼리) 

잘 모르겠는 것 : 

"현재 웹 애플리케이션 레이어라고 부르는 것에는 인접하는 레이어에 대한 단방향 액세스뿐만 아니라, 상호의존을 하는 것도 있습니다. 이러한 것은 레이어가 아닙니다. 단지 화면 쪽이나 데이터베이스 쪽에 관련된 내용입니다. 이러한 현상을 발견하면 리팩터링하는 것이 좋습니다. "

?? UML보면 데이터 액세스 층이랑 비즈니스로직 층이 상호의존중인데 그럼 이게 바람직하지 못하다는 건가? 근데 왜 이 UML로 설명하고 있는거지?? 무슨 말이지??!

 

 

 

---

- 끝 - 

 

웹 애플리케이션 아키텍처의 주요한 부분인 레이어 개념을 공부했다.

자바 소프트웨어 구현 공부할 때 & 스프링 맛보기할 때 봤던 컨트롤러, 서비스, Dao, 여러 도메인들이 오늘 배운 레이어 개념이었다. 그때는 아무 것도 모르고 아 그냥 서비스 구현할 때 기능을 이런식으로 나누는구나~ 했는데 웹 애플리케이션의 중간 계층(애플리케이션 서버)을 레이어라는 논리 구조로 나누는 거였구나!!! 

 

 

다음 학습 : 레이어의 각 층의 역할을 좀 더 자세히

- 프레젠테이션 층

- 비즈니스 로직 층

- 데이터 액세스 층