웹애플리케이션 아키텍처

애플리케이션 아키텍처

책임과 성격이 다른 것을 크게 그룹으로 만들어 분리해두는 것을 아키텍처 차원에서는 계층형 아키텍처(layered architrecture)라고 부른다. 또는 계층이라는 의미를 가진 영어 단어인 티어(tier)를 써서 멀티 티어 아키텍처라고도 한다.

(보통 3계층 3-tier 혹은 3-layer)애플리케이션이라고도 한다.

3계층 아키텍처와 수직 계층

3계층 아키텍처는 백엔드의 DB나 레거시 시트메과 연동하는 인터페이스 역할을 하는 데이터 엑세스(DataAccess)계층

비즈니스 로직을 담고있는 서비스 계층

주로 웹 기반의 UI를 만들어내고 그 흐름을 관리하는 프레젠테이션 계층으로 구분

클라이언트 <-> 프레젠테이션 계층 <-> 서비스계층 <-> 데이터 엑세스 계층 <-> DB/레거시

데이터 엑세스 계층

DAO 계층이라고 불리면, DB 외에도 ERP, 레거시 시스템, 메인 프레임 등에 접근하는 역할을 하기 때문에 (EIS)계층이로고도 한다. (Enterprise Information System)

하지만 대개는 장기적인 데이터 저장을 목적으로 하는 DB 이용이 주된 책임이다.

데이터 엑세스 계층은 사용 기술에 따라서 다시 세분화된 계층으로 구분될 수 있다.(추상화 수준에 따른 구분이기 때문에 수직적인 계층이라고도 부른다)

JdbcTemplate이 추상화를 위한 계층으로 사용돼서 로우레벨의 기반 계층에 존재하는 JDBC와 드라이버, 스프링의 트랜잭션 추상화 서비스 동기화 기능을 간접적으로 이용하게 만든다는 것이다.

서비스 계층

가장단순한 계층. 잘 만들어진 스프링  애플리케이션의 서비스 계층 클래스는 이상적인 POJO로 작성된다.

POJO로 만든다면 객체지향적인 설계 기법이 적용된 코드를 통해서 비즈니스 로직의 핵심을 잘 담아내고, 이를 쉽게 테스트하고 유연하게 확장할 수 있다. 서비스 계층은 DAO 계층을 호출하고 이를 활용해서 만들어진다.

서비스 계층과 기반 서비스 계층, DAO 계층의 관계를 나타낸 것

여기서는 기반 서비스 계층이 3계층 어디에서나 접근이 가능한 구조로 설정했다.

눈여겨봐둘 것은 기반 서비스 계층이 서비스 계층의 오브젝트를 호출하는 경우다. 일반적으로 서비스 계층이 필요에 따라 기반 서비스 계층의 API를 호출해서 이용한다. 스케줄링이 대표적인 경우다. 미리 정해진 시간에 특정 서비스 계층의 로직이 동작하게 만드는 백그라운드 서비스가 필요하다면 그때는 기반 서비스 계층에서 서비스 계층의 오브젝트를 이용하게 할 수 도 있다.

이상적인 서비스 계층은 백엔드 시스템과 연결되는 데이터 엑세스 계층이 바뀌고, 클라이언트와 연결되는 프레젠테이션 계층이 모두 바뀌어도 그대로 유지될 수 있어야 한다. (엔터프라이즈 애플리케이션에서 가장 중요한 자산은 도메인의 핵심 비즈니스 로직이 들어 있는 서비스 계층이어야 한다.)

프레젠테이션 계층

가장복잡한 계층이며, 매우 다양한 기술과 프레임워크의 조합을 가질 수 있다.끊임없이 발전하고 진보하고 새로운 모델이 등장하기 때문이다.(flex, extjs, reactjs, ... )

단순한 HTML 과 자바스크립트만을 사용하는 브라우저이든, 플러그인 안에서 동작하는 플래시 애플리케이션이나 액티비 X 기반의 애플리케이션이든.. 대부분의 엔터프라이즈 애플리케이션을 사용하는 클라이언트들은 HTTP 프로토콜을 선호한다. 따라서 이런 클라이언트와 연결돼서 동작하는 프레젠테이션 계층은 자바에서 HTTP 프로토콜을 처리하는 가장 기본 엔진이 서블릿 기술을 바탕으로 한다.

초기는 클라이언트 모델은 단순히 HTML로 만들어진 결과를 사람이 볼 수 있도록 그려주고, 폼을 통해 입력받은 값을 전달하는 것이었다. 모든 프레젠테이션 로직은 서버의 프레젠테이션 계층의 컴포넌트에서 처리된다.

화면 흐름을 결정하는 것이나 사용자 입력 값에 대한 검증, 서비스 계층의 호출과 전달되는 값의 포맷의 변화, 뷰라고 불리는 화면을 어떻게 그릴지에 대한 로직 등이 모두 서버에서  처리됐다.

=> 최근에는 점점 많은 프레젠테이션 로직이 클라이언트로 이동하고 있다. (RIA 라고 불리는 기술이나 SOFEA 아키텍처가 대표적인 예이다.) RichInternetApplication, Service Oriented Front End Architruectre

각 계층은 응집도가 높으면서 다른 계층과는 낮은 결합도를 유지할 수 있어야 한다.

흔히 저지르는 실수 중의 하나는 프레젠테이션 계층의 오브젝트를 그대로 서비스 계층으로 전달하는 것이다. 서블리스이 HttpServletRequest나 HttpServletResponse, HttpSession 같은 타입을 서비스 계층 인터페이스 메소드의 파라미터 타입으로 사용하면 안된다. 계층의 경계를 넘어갈 때는 반드시 특정 계층에 종속되지 않는 오브젝트 형태로 변환해줘야 한다.

만약 서비스 계층의 코드에 웹 프레젠테이션 계층의 기술이 노출했다고 해보자. 웹 방식의 클라이언트가 아닌 다른 시스템에서 요청을 받아서 처리해야 하는 경우에는 웹 기술에 종속된 코드는 재사용이 불가능해진다.

같은 로직을 가졌지만 클라이언트의 종류에 따라서 비즈니스 로직 코드가 달라지는 결과를 초래할 수도 있음.

=> 계층사이의 낮은 결합도를 깨뜨리지 않도록 설계해야 한다.

출처, 참고서적 및 그림 : 토비의 스프링3

정리

---

Presentation Layer

• UI를 담당하는 구성요소가 들어감
• 웹인지 모바일 앱인지에 따라 사용되는 기술이 변경

Business Layer(서비스 계층)

• 서비스 계층이라고도 부르며, 기능적인 요구사항을 구현한 곳
• 어떤 형태의 데이터가 필요하고, 반환될 것인지를 결정

DataAccess Layer

• Persistence Layer라고도 하는데, 데이터 처리를 전문적으로 담당