글 작성자: 써니루루
자료 출처 : http://blog.naver.com/an5asis?Redirect=Log&logNo=60018329312

티어와 레이어는 물리적으로 구조를 잡았는가와 논리적으로 구조를 잡았는가에 따라 물리적인 단계를 티어, 논리적인 구분을 레이어라 합니다.

이런 티어와 레이어의 단계는 시스템의 구조를 설계하는 방법에 따라 여러단계가 나올 수 있고 간단한 구조가 나올 수 있습니다.

아래는 좀 더 자세히 설명해 놓은 글입니다.

항상 몇단계의 레이어와 티어가 나오는 것은 아니고, 자신이 설계한 것에 따라 시스템의 티어 레이어가 나온다는 점을 유념해야 합니다.


이하는 원문 주소의 내용입니다.






레이어(Layer)는 아키텍처 패턴의 일종으로 볼 수 있다. 워낙 보편적인 개념이어서 소프트웨어 공학쪽에서 출현한 기원은 모르겠지만, POSA1(A system of patterns by Frank Buschmann et al.)에 등장한다.
 
The Layers architectural pattern helps to structure applications that can be decomposed into groups of subtasks in which each group of subtasks is at a particular level of abstraction.
 
추상화의 정도가 다른 작업들을 분리하여 묶어놓을 수 있는 장치로 인식할 수 있다. 대표적인 예로 OSI 7 Layer 참조 모델을 들었다.


그림 출처: http://searchnetworking.techtarget.com/WhatIs/images/osi.gif
 
먼저 이것은 서랍을 나누어서 물건을 넣어두는 것과 같은 분류의 이점을 기본적으로 해서, 동류의 기능들을 한쪽에 위치하게 하여 복잡도를 제어할 수 있다. 여기에 더하여, 추상화라는 개념이 들어가는데, 이것은 높고 낮음이 있는 일관된 기준이다. 즉, 층을 이루게 세워둘 수 있다는 것이고, 접하지 않는 층 혹은 레이어끼리는 직접 적인 상호작용을 막아 또 한번 복잡도를 걸러준다.
 
최근 들어서는 티어와 레이어가 다소 혼용되는 감이 있는데, 티어는 기본적으로 다소 물리적인 배포를 취급하는 측면이 강하고, 레이어는 논리적인 분할이라고 할 수 있다.
 
아래 그림은 JavaOne 2001에서 발표했던 EJB 중심의 MVC 레이어를 표현한 것이다.


 
크게 화면을 책임지는 프레젠테이션과 비즈니스 로직을 담은 서비스와 데이터 저장을 책임지는 리소스 세개로 레이어를 분할했다. 특징적인 점은 이들 사이에서 세부적인 레이어를 더 분할했다는 것이다. 상위 레이어와의 접점에는 어댑터(Adapter)를 두고, 어댑터와 실제 로직 사이에는 호출(Invocation) 게층을 추가했다. 로직에 해당하는 부분만 비즈니스 개발자 혹은 컴포넌트 개발자가 하게 하고 나머지는 EJB 컨테이너가 돕겠다는 것인데... EJB는 그렇다 치고 이러한 분할은 괜찮아 보입니다.
 
동일한 모습을 가로로 눕혀보면, 티어와 유사하게 배치가 됩니다.


다양한 형태의 사용자 혹은 액터(Actor)가 프리젠테이션쪽에 접하게 되고, 리소스 로직은 데이터베이스나 레거시 시스템 같은 것들과 접하게 되죠. 아래 놓이는 Context Model Layer는 상황에 따른 정보들, 그래서 다른 레이어를 넘나들어 Layers 아키텍처 패턴의 이점을 해치는 층이죠. AOP와 같은 개념들은 이러한 단점을 해결해줄 수 있을런지도 모르겠습니다만... 아무튼 세션이니 트랜젝션이니 하는 골치 아픈 것들이 죄다 모여 있는 곳이라고 할 수 있죠.
 
TCP/IP 통신과 비교해보면, 헤더에 해당한다고 할까요? 그다지 적절해보이지는 않지만, 유사한 감이 있는 것 같네요. ㅡㅡ;
 
이 그림을 보죠. 아주 직관적입니다.
 
POJO 기반 웹 어플리케이션을 기준으로 레이어를 분할한 모습이라 이해하기는 쉽습니다. 그런데, 웹에 초점을 맞추고 있어서 대게 프레젠테이션 레이어로 보는 층을 요청(Request)과 세션(Session)으로 둘로 나눴습니다.
 
그리고, 요청과 세션 구분은 명확하지만 세션과 비즈니스 사이는 애매하죠. 분명한 설계전략이 없이 Struts 액션을 사용하면 이렇게 되는 경우가 많죠. 그리고, 데이터베이스가 비즈니스와 퍼시스턴스 사이에 위치하는데, 글쎄요 의도적으로 이렇게 그린건지. 예를 들어 조회같은 것을 할 때, 해당 데이터베이스에서만 쓸 수 있는 SQL Dialect를 직접 비즈니스 객체에 넣는다면 이러한 그림이 합당하겠네요. 물론 바람직한 현상이라고 볼 수는 없죠. 한번 구축하고 말 작은 시스템이라면 얘기가 틀리지만
 
웹 기반 어플리케이션이 성행하면서 가장 흔하게 등장하는 레이어링 기준은 MVC입니다.
Best Practices "JSP Model 2" MVC Web Application Architecture
 
Sun의 PetStore에 대응하여 오라클이 만든 ADF Toy Store의 MVC 레이어 구분입니다.  그대로 일대일 대응을 시키는 것은 맞지 않지만, 대체로 모델은 리소스쪽에 해당하고, 뷰는 프리젠테이션, 컨트롤러는 서비스라고 할 수 있습니다.
 
그러나, Struts 기반의 웹 어플리케이션을 짜면서 모델을 바로 DB에 연결하고, 컨트롤러를 Action으로 하고, 뷰를 JSP로 하면... 재사용 모듈은 하나도 나오지 않고, 온통 Struts를 이용해야만 돌아가게되는 문제가 발생합니다.ㅡㅡ;
 
Struts 등의 웹 MVC 를 사용할 때는 전체가 다 뷰에 해당한다고 보는 것이 적잘할 것 같습니다. 그러니까, 프리젠테이션 레이어 내에서 다시 MVC를 사용하고 있다고 봐야죠. 어렵나요. ㅡㅡ;
 
아무튼, 관점에 따라 분할이 다를 수 있습니다. MVC적인 사고로 레이어를 3분할하면
프리젠테이션
서비스 혹은 비즈니스
리소스 혹은 인티그레이션(Integration)
 
위와 같은 분할이 보편적이라고 생각되구요, 만약 4분할 한다면
프리젠테이션
서비스 혹은 비즈니스 로직
도메인 혹은 비즈니스 데이터
리소스 혹은 인티그레이션(Integration)
 
이러한 레이어분류내에서 Struts 등의 웹 MVC 프레임워크는 프리젠테이션 레이어를 JSP등의 뷰 기술과 함께 놓이는 것이라 할 수 있구요. 서비스쪽은 자바빈 형태나 세션빈 형태가 되겠죠. 도메인이나 비즈니스 데이터는 POJO난 엔터티빈에 해당하겠구요. 리소스는 데이터베이스 연결 기술이나 커넥터 기술이 되겠죠.
 
그러나, 4계층보다는 J2EE Architect's Handbook에서 제안한 5계층이 더 좋아보입니다. 서비스나 비즈니스 로직을 바로 EJB에 넣어 발생하는 문제(테스트가 어렵고, 객체 지향 설계가 깨지고, 재사용이 어려워짐)는 막으면서, 자바빈 형태로 서비스를 구현하고 필요하면 디플로이먼트 레이어에서 EJB로 래핑(Wrapping)하는 전략이죠. Spring에서는 이러한 접근을 그대로 적용할 수 있게 해줍니다.
프리젠테이션
디플로이먼트(Deployment)
서비스 혹은 비즈니스 로직
도메인 혹은 비즈니스 데이터
리소스 혹은 인티그레이션(Integration)
 
그럼 복잡한 그림들을 보면서 레이어와 티어에 대한 이해를 견고히 해보죠. 복잡한 그림에도 흔들리지 않게.. ^^;


 
이 그림은 IBM의 마케팅 전략인 On Demand를 수용하느라 상당히 복잡하게 그려낸 것입니다. 구현 가능성보다는 개념적인 수준에서 충실하게 표현하려고 하려는 것이었겠죠. 프리젠테이션이라고 할 수 있는 부분을 사용자 접근 서비스와 사용자 상호작용으로 나눴는데, 이것은 뷰 기술과 웹 MVC와 대응되는 것이라고 할 수 있습니다.
 
서비스 혹은 비즈니스 레이어에 해당하는 부분을 네 개의 블럭으로 나눠놓았구요. 리소스 부분은 인프라에서 전면 커버하겠다는 전략이죠.
 
이것보다는 좀 더 나은 그림이 있습니다.


 
네 개의 티어에 컴포넌트를 위치시켰는데요. 각각의 컴포넌트는 레이어에 매핑되는 것들인데, 티어에는 그대로 놓인다기 보다 걸쳐지게 되죠. 이런 것들이 현실을 반영한 그림이죠. 물리적인 티어와 논리적인 레이어와의 차이를 대변해주기도 하는 좋은 그림이네요.

티스토리툴바