1부 이야기 - 계층화

마틴 파울러의 엔터프라이즈 애플리케이션 아키텍처 패턴을 읽고 정리한다.

1부 이야기에서는 다양한 개념과 발전 과정을 말한다.

작성 시점은 20년 전으로 당시와 지금의 용어가 약간 다를 수 있고, 더 이상 사용 안 하는 것도 있을 수도 있다.

자세한 내용이 궁금하면 읽어보는 걸 권한다.

엔터프라이즈 애플리케이션 아키텍처 패턴(재출간판) - 교보문고

---

계층화

계층화(layering)는 소프트웨어 설계자가 복잡한 소프트웨어 시스템을 분할하는 데 사용하는 가장 일반적인 기법이다.

계층의 관점에서 시스템을 보면 하위 계층 위에 다음 상위 계층이 있는 일종의 레이어 케이크와 같은 형식의 원리 체계가 머릿속에 떠오른다. 이 체계에서 상위 계층은 하위 계층이 정의하는 다양한 서비스를 사용하지만, 하위 계층은 상위 계층을 인식하지 못한다.

(Controller, Service, Repository 구조를 생각해보자, Repository는 Service를 인식하지 못하고, Service는 Controller를 인식하지 못한다. 하지만 반대로 Controller는 Service를 사용하고 Servlce는 Repository를 사용한다.) 

 

시스템을 계층으로 분할하면 여러 장점이 존재한다.

- 다른 계층 정보 없이, 단일 계층을 하나의 일관된 계층으로 이해

- 동일한 기본 서비스를 가진 대안 구현으로 계층을 대체

- 계층 간의 의존성을 최소화

- 계층은 표준화하기 좋은 위치

- 구축된 계층은 다른 상위 서비스에서 사용 가능

 

반면에 단점도 존재한다.

- 계층은 전체가 효과적으로 캡슐화되지 않는다. 변경되면 다른 계층에 영향이 간다.

- 계층이 추가되면 성능이 저하된다. 각 계층간 정보를 변환시켜야 한다. 다만, 기반 기능을 캡슐화하면 효율이 향상될 수 있다. ex)트랜잭션 제어 계층 최적화

---

엔터프라이즈 애플리케이션에서 계층의 발전

계층의 개념은 90년대 클라이언트-서버 시스템의 등장과 함께 좀 더 중요해졌다. 클라이언트가 사용자 인터페이스와 다른 애플리케이션 코드를 포함하고 서버가 관계형 데이터베이스를 포함하는 2계층 시스템이다.

애플리케이션의 기능이 주로 관계형 데이터를. 표시하고 간단한 업데이트를 수행하면 이러한 클라이언트-서버시스템은 잘 동작한다. 문제는 비즈니스 규칙, 유효성 검사 같은 도메인 논리를 수행하는 경우에 일어난다. 

클라이언트의 UI화면에 논리를 삽입하는 경우가 많았고, 변화가 생길 때 작업하기 매우 어려워졌다. 또한 코드 복제가 쉬워 비슷한 코드를 찾아 수정해야 했다.

이 문제의 대안으로 도메인 논리를 저장 프로시저로 만들어 데이터베이스에 저장하는 방법이 있다.

저장 프로시저는 제한적인 구조화 메커니즘과 제품마다 다르기 때문에 데이터베이스를 교체하기 어렵다.

 

다른 한쪽에서 객체지향의 세계가 시작됐다. 도메인 논리 문제에 대한 해결책으로 3계층 시스템을 제안했다.

UI를 위한 프레젠테이션 계층, 도메인 논리를 위한 도메인 계층, 그리고 데이터 원본을 이용한다.

하지만 객체지향 기법은 큰 진전을 이루지 못했다. 그 당시 시스템이 너무 간단했기 때문이다. 

 

그러다가 웹이 등장하면서 클라이언트-서버에서 웹 브라우저로 변하기 시작했다. 기존 비즈니스 논리가 리치 클라이언트 안에 포함되어 있었고 웹 인터페이스로 바꾸기 위해 전면적으로 수정해야 했다. 올바르게 설계된 3계층 시스템이라면 쉽게 해결할 수 있었다.

이 즈음에는 객체지향 언어인 자바가 프로그래밍 주류로 자리 잡았다.

 

계층(layer)과 티어(tier)를 혼동하는 경우가 많다. 일반적으로 티어는 물리적 분리를 함축하는 경우가 많다. 클라이언트-서버 시스템의 경우 클라이언트는 데스크톱에 있고 서버는 서버에 있기 때문에 물리적으로 분리되어 2티어 시스템이라 부른다. 

 

---

세 가지 주요 계층

계층	역할
프레젠테이션	서비스 제공, 정보 표시(창 또는 HTML), 사용자 요청(마우스 클릭, 키 누름), HTTP 요청, 명령줄 호출, 일괄 작업 API 처리
도메인	시스템의 핵심이 되는 논리
데이터 원본	데이터베이스, 메시징 시스템, 트랜잭션 관리자 및 다른 패키지와의 통신

프레젠테이션(presentation) 논리는 사용자와 소프트웨어 간 상호작용을 처리한다. 주 역할은 사용자에게 정보를 표시하고 사용자가 내린 명령을 도메인과 데이터 원본에서 처리한다.

데이터 원본(data source) 논리는 애플리케이션을 대신해 다른 시스템과 통신한다. 대부분 엔터프라이즈 애플리케이션에서 가장 큰 원본 데이터 논리는 지속성 데이터를 저장하는 데이터베이스다.

도메인 논리(domain logic)는 비즈니스 논리라고 부른다. 애플리케이션이 수행해야 하는 도메인과 관련된 작업으로 입력된 데이터 계산, 유효성 검사 같은 작업이 포함된다.

 

모든 엔터프라이즈 애플리케이션에 대해 세 가지 공통적인 역할 계층을 파악할 수 있지만, 계층을 구분하는 방법은 애플리케이션이 얼마나 복잡하냐에 따라 달라지며 상황에 맞게 분리하는 선택을 해야 한다.

분리 외에도 의존성에 대한 규칙이 있다. 도메인과 데이터 원본은 프레젠테이션에 의존하지 않아야 한다. 그래야 다른 프레젠테이션으로 쉽게 교체할 수 있고, 수정하기도 편하다.

---

계층이 실행될 위치 선택

계층이 실행될 위치는 클라이언트, 데스크톱 시스템 또는 서버 같은 물리적 구조가 차이를 만드는 경우도 있다.

가장 간단한 방법은 모든 것을 서버에서 실행하는 것이며, 웹 브라우저를 활용하는 HTML 프런트엔드가 좋은 예다.

서버에서 모든 걸 실행하는 장점은 업그레이드하거나 수정하기 쉽다는 것이다. 물리적 구조가 분산되어 있지 않으니 버전에 따른 호환성 같은 문제를 신경 안 써도 된다.

 

클라이언트 실행을 선호하는 사람들은 응답성이나 비연결 유리함을 근거로 든다. 서버에서 실행되면 사용자의 작업에 따라 서버로 응답이 왕복되는데, 빠른 피드백을 원한 사용자에겐 이 왕복이 방해가 되고, 네트워크가 연결되어야 한다는 단점이 있어 네트워크 연결 없이 작업을 원하는 사용자가 있다. (책의 작성 시점은 네트워크 연결이 힘든 시대다)

 

계층별로 선택할 수 있는 위치를 알아보자.

데이터 원본은 거의 서버에서 실행한다. 예외 사항은 비연결 작업을 위해 서버 기능을 고성능 클라이언트에 복제하는 경우다.

 

프레젠테이션 계층을 실행하는 위치는 사용자가 원하는 인터페이스의 유형에 따라 달라진다. 리치 클라이언트(네트워크 연결 없이 실행되는 프로그램)의 경우 거의 대부분 클라이언트에서 프레젠테이션 계층을 실행한다. 웹 인터페이스의 경우 대부분 서버에서 실행한다.

 

도메인 논리는 서버 또는 클라이언트 실행하거나 분할해서 실행할 수 있다. 유지 관리를 생각하면 서버가 최선의 방법이다. 클라이언트에서 실행하는 이유는 응답성을 개선하거나, 비연결 작업을 지원하기 위해서다.

클라이언트와 서버에 논리를 분할하는 방법은 기준이 없기 때문에 최악의 선택으로 보일 수 있다. 이 방법은 클라이언트에 도메인 논리를 적게 실행할 때 선택하며, 해당 논리가 외부에 의존하지 않게 독립적으로 만드는 것이 좋다.