[토비의 스프링] 9장: 스프링 프로젝트 시작하기

토비의 스프링: Vol. 1: 스프링의 이해와 원리

 

스프링은 주로 자바 엔터프라이즈 환경에서 동작하는 애플리케이션을 개발하는 목적으로 사용됨

아키텍처: 어떤 경계 안에 있는 내부 구성요소들이 어떤 책임을 갖고 있고, 어떤 방식으로 서로 관계를 맺고 동작하는지를 규정하는 것

시스템 레벨 아키텍처 결정하기

스프링 엔터프라이즈 애플리케이션의 서비스와 협력 구조

애플리케이션 서버

스프링으로 만든 애플리케이션을 자바 서버환경에 배포하려면 JavaEE(.J2EE) 서버가 필요함

JavaEE 서버 종류

• WAS(Web Application Server): 완전한 웹 애플리케이션 서버
• 경량급 WAS / 서블릿 컨테이너: 톰캣(Tomcat) 등의 가벼운 서블릿 컨테이너

실제 개발환경과 운영환경에서 가장 많이 사용되는 자바 서버는 웹 모듈만 지원하는 서블릿 컨테이너인 아파치 톰캣

스프링 애플리케이션의 배포 단위

• 독립 웹 모듈
• 엔터프라이즈 애플리케이션
• 백그라이누드 서비스 모듈

개발도구와 환경

• JavaSE/JDK, JavaEE/J2EE
• IDE: 통합개발환경
• 빌드 툴/라이브러리 관리: Maven 등

Maven의 특징: POM이라 불리는 프로젝트 모델 정보를 이용하여 빌드 또는 프로젝트 관리 작업을 진행할 수 있음

• POM에서 의존 라이브러리를 선언해두기만 하면 자동으로 라이브러리를 다운로드 받아서 사용 할 수 있게 해줌
• 전이적 의존 라이브러리 추적 기능으로 라이브러리가 동작하는데 필요한 다른 라이브러리까지 함께 다운로드 해줌

애플리케이션 아키텍처 결정하기

계층형 아키텍처(layered architecture): 책임과 성격이 다른 것을 크게 그룹으로 만들어 분리해두는 것

웹 기반의 엔터프라이즈 애플리케이션은 일반적으로 세 개의 계층을 갖는다고 해서 3계층 애플리케이션이라고 불림

3계층 아키텍처

• 데이터 액세스 계층: 백엔드의 DB나 레거시 시스템과 연동하는 인터페이스 역할을 하는 계층
• 서비스 계층: 비즈니스 로직을 담고 있는 계층
• 프레젠테이션 계층: 웹 기반의 UI를 만들어내고 그 흐름을 관리하는 계층

엔터프라이즈 애플리케이션의 프레젠테이션 계층은 클라이언트의 종류와 상관없이 HTTP 프로토콜을 사용하는 서블릿이 바탕이 됨

계층형 아키텍처 설계의 원칙: 각 계층은 응집도가 높으면서 다른 계층과는 낮은 결합도를 유지할 수 있어야 한다

애플리케이션 정보 아키텍처: 애플리케이션을 사이에 두고 흘러다니는 정보를 어떤 식으로 다룰지를 결정하기

데이터 중심 아키텍처

데이터 중심 아키텍처: 단순히 값이 값을 담기 위한 오브젝트 형태로 취급하는 아키텍처 → 객체지향의 요소가 없음

• DB/SQL 중심의 로직 구현 방식
• 거대한 서비스 계층 방식

데이터 중심 아키텍처의 특징은 계층 사이의 결합도가 높은 편이고 응집도는 떨어진다는 점임

오브젝트 중심 아키텍처

오브젝트 중심 아키텍처: 도메인 모델을 반영하는 오브젝트 구조를 만들어두고 그것을 각 계층 사이에서 정보를 전송하도록 하는 아키텍처 = 오브젝트를 만들어두고 오브젝트 구조 안에 정보를 담아서 각 계층 사이에 전달하게 만드는 아키텍처

장점

• 일관된 의미를 가지고 유연하며 애플리케이션 전반에 공유 가능한 도메인 모델을 따르는 오브젝트로 정보를 다루기 때문에 코드는 이해하기 쉽고, 로직을 작성하기도 수월함
• 각 계층은 이미 정의된 도메인 오브젝트 구조만 알고 있으면 됨
• 코드의 재사용성은 높아지고 DAO는 더 작고 효율적으로 만들어질 수 있음

단점

• 매번 SQL을 통해 오브젝트의 필드 전체를 가져와야 하기 때문에 최적화된 SQL보다 성능 면에서 손해를 볼 수 있음
• 한 오브젝트를 가져오기 위해 해당 오브젝트와 관계된 모든 오브젝트들을 추가로 가져와야 한다

해결방법

• 지연된 로딩(lazy loading) 기법: 최소한의 오브젝트 정보만 읽어두고 관계하고 있는 오브젝트가 필요한 경우에만 다이내믹하게 DB에서 다시 읽어오는 기법
• 오브젝트/RDB 매핑 (ORM) 기술: 지연된 로딩 기법 등을 제공하며, SQL 결과를 가지고 자동으로 도메인 오브젝트를 만들어줌, SQL 최적화 또한 가능함

오브젝트 중심의 아키텍처는 도메인 모델을 따르는 오브젝트를 사용해 각 계층 사이에 정보를 전달하고, 이를 이용해 비즈니스 로직이나 프레젠테이션 로직을 작성한다. 계층 간의 결합은 낮아지고 일관된 정보 모델을 사용하기 때문에 개발 생산성과 코드의 품질, 테스트 편의성도 향상시킬 수 있음

그런데 도메인 오브젝트는 자바오브젝트이기 떄문에, 데이터 저장 뿐만 아니라 내부 정보를 이용하는 기능도 함께 가지고 있어야 함. 클래스는 속성(attribute)와 행위(operation)의 조합이기 때문에, 속성만을 이용하는 오브젝트는 반쪽짜리임. 따라서 도메인 오브젝트의 사용을 데이터 저장만으로 제한할 필요가 없음. 더 적극적으로 활용하게 만들어야 함

오브젝트의 활용 방법

빈약한 도메인 오브젝트 방식

도메인 오브젝트에 정보만 담겨 있고, 정보를 활용하는 아무런 기능도 갖고 있지 않는 빈약한(anemic) 오브젝트

빈약한 도메인 오브젝트 방식의 구조

(데이터 중심 아키텍처의 거대 서비스 계층구조와 비슷함)

풍성한 도메인 오브젝트 방식

특정 도메인 오브젝트나 그 관련 오브젝트가 가진 정보와 깊은 관계가 있는 비즈니스 로직을 서비스 계층의 코드가 아니라 도메인 오브젝트에 넣어주고, 서비스 계층의 비즈니스 로직에서 재사용하게 만드는 것

풍성한 도메인 오브젝트 방식의 구조

도메인 계층 방식

도메인 오브젝트들이 하나의 독립적인 계층을 이뤄서 서비스 계층과 데이터 액세스 계층의 사이에 존재하게 하는 것

특징

• 도메인에 종속적인 비즈니스 로직의 처리는 서비스 계층이 아니라 도메인 계층의 오브젝트 안에서 진행됨
• 도메인 오브젝트가 기존 데이터 액세스 계층이나 기반 계층의 기능을 직접 활용할 수 있음 (AspectJ AOP로 오브젝트 DI)

도메인 오브젝트를 독립적인 계층으로 만들려고 할 떄 고려해야 할 중요한 사항: 도메인 오브젝트가 도메인 계층을 벗어나서도 사용되게 할지 말지 결정하기

1. 모든 계층에서 도메인 오브젝트 사용하기
2. 도메인 오브젝트는 도메인 계층을 벗어나지 못하게 하는 것

도메인 계층 방식의 구조

도메인 계층 방식의 특징: 도메인 계층의 오브젝트는 매우 짧은 시간 동안만 존재했다가 사라짐 → 생명주기가 짧음

도메인 계층 방식을 채택해야 하는 경우: 매우 복잡하고 변경이 잦은 도메인을 가졌을 때

DTO와 리포트 쿼리

• 도메인 계층 방식의 경우 도메인 계층을 벗어난 정보를 DTO에 담아 사용하기도 함
• DTO가 필요한 또다른 경우: 리포트 쿼리의 실행 결과를 담는 경우

웹 서비스 등의 시스템과 자료를 주고받을 때 전송 규약에 맞춰서 도메인 오브젝트에 담긴 정보를 가공할 때도 DTO를 사용하여 해당 형식에 맞도록 변경하는 작업을 수행하기도 함

스프링 애플리케이션을 위한 아키텍처 설계

계층형 아키텍처

스프링을 사용하는 엔터프라이즈 애플리케이션에서는 3계층 구조를 가장 많이 사용함

2계층으로 만든다면 서비스 계층과 데이터 액세스 계층을 통합함

프레젠테이션 계층은 보통 MVC 패턴/아키텍처를 주로 사용함

프레젠테이션 계층은 클라이언트까지 확장되기도 함

SOFEA(Service Oriented Front End Architecture)

정보 전송 아키텍처

스프링의 기본 기술에 가장 잘 들어맞고 쉽게 적용해볼 수 있는 것은 오브젝트 중심 아키텍처의 도메인 오브젝트 방식

상태 관리와 빈 스코프

애플리케이션 유지해야 하는 다양한 상태정보가 있음

상태정보 저장을 스프링은 기본적으로 상태가 유지되지 않는 빈과 오브젝트를 사용하는 것을 권장함

스프링은 다른 스코프를 갖는 빈을 간단히 만들 수 있으므로 이를 활용 할 수 있음

서드파티 프레임워크, 라이브러리 적용

스프링은 거의 대부분의 자바 표준 기술과 함꼐 사용될 수 있음

오픈소스 프레임워크, 라이브러리는 스프링이 지원하는지 확인해야 함

스프링이 지원하는 기술이란?

1. 스프링의 DI 패턴을 따라 사용할 수 있는 기술
2. 스프링의 서비스 추상화가 적용된 기술
3. 스프링이 지지하는 프로그래밍 모델을 적용한 기술
4. 템플릿/콜백을 지원하는 기술

정리

스프링으로 애플리케이션 프로젝트를 만들면서 초기에 결정해야 할 것들

1. 시스템 레벨 아키텍처 결정하기
2. 애플리케이션 아키텍처 결정하기
3. 서드파티 기술/라이브러리 접근 방법 결정하기

주요 내용

• 스프링은 어떤 플랫폼에서도 사용될 수 있지만, 기본적으로는 자바 엔터프라이즈 플랫폼(JavaEE)에 최적화되어 있다. HTTP를 통해 접근하는 웹 클라이언트와 백엔드 DB를 사용하는 애플리케이션에 적합하다
• 스프링 개발의 생산성을 증대시키고 품질을 높이려면 IDE 등의 적절한 툴의 지원이 필요하다
• 스프링은 의존 라이브러리가 방대하기 때문에 라이브러리 관리와 의존관계를 관리하는 데 많은 노력을 기울여야 한다. 가능하면 스프링이 의존관계 정보를 제공해주는 Maven 등의 빌드 툴을 사용해 의존 라이브러리를 관리하는 것이 바람직하다
• 스프링 애플리케이션은 역할에 따라 3계층으로 구분되고, 다시 기술의 추상도에 따라 세분화되는 계층형 아키텍처를 사용하는 것이 좋다
• 아키텍처는 애플리케이션이 다루는 정보의 관점에서 데이터 중심과 오브젝트 중심으로 구분할 수 있다
• 스프링에 가장 잘 어울리는 아키텍처는 오브젝트 중심의 아키텍처다
• 스프링이 직접 지원하지 않는 서드파티 기술도 스프링 스타일의 접근 방식을 따라서 사용할 수 있도록 준비해둬야 한다

 

Reference: http://www.yes24.com/Product/Goods/7516721

토비의 스프링 3.1 Vol. 1 스프링의 이해와 원리 - YES24