토비의 스프링 - 9장

이번 9장을 마지막으로 스프링 스터디를 마무리 하게 되었습니다.

9장의 주 내용은 스프링 개발을 할 때 알아둬야 하는 구성 정보와 스프링 개발에 도움을 주는 툴, 빌드 방법과 스프링 어플리케이션에 적용 가능한 아키텍처를 알아보는데 스터디에서는 개발에 도움을 주는 툴과 빌드 방법을 제외하고 진행하게 되었습니다.

스프링의 탄생 배경이나 스프링이 주로 제공하는 기술을 보면 사실 스프링으로 만들 수 있는 어플리케이션의 제한은 없습니다. 어떤 클라이언트냐에 따라 추가적인 기술 지원이 필요하지만 기본적으로 자바 언어를 사용하는 프로젝트라면 어디서든 사용 할 수 있습니다. 그 중에서도 저희는 웹을 기반으로 하는 환경에서 사용하는 방법에 대해서 좀 더 자세히 알고 있습니다.

자바 엔터프라이즈 어플리케이션은 크게 클라이언트와 백엔드로 나뉘게 되는데 가장 많이 사용되는 구조로 웹 브라우저를 클라이언트로 하고 백엔드 시스템이 DB인 구조가 있습니다. 이런 구조가 주로 쓰이기 때문인지 스프링의 주요 기능도 이러한 부분에 초점이 맞춰져 있습니다. 그런데 사실 자바 서버가 받아 들일 수만 있다면 어떤 종류의 클라이언트라도 상관이 없습니다.

이런 스프링 어플리케이션을 배포 할 때는 JavaEE 서버가 필요한데 이런 JavaEE 표준을 따르는 어플리케이션 서버는 크게 2가지로 볼 수 있습니다.

• WAS (Web Application Server) : 웹 서버와 DBMS 사이에서 동작하는 미들웨어
• 경량급 WAS : WAS 에서 웹 모듈의 배포만 가능한 것을 경량급이라고 부릅니다.
• tcServer : 경량급 WAS 로 자주 쓰이는 아파치 톰캣을 기반으로 스프링소스(스프링 개발을 책임지는 회사)에서 스프링 어플리케이션에 최적화된 경량급 WAS

배포 단위도 그에 따라 세가지로 나뉩니다.

• 독립 웹 모듈 : 보편적으로 war 로 패키징된 독립 웹 모듈로 배포
• 엔터프라이즈 어플리케이션 : ear 로 패키징된 하나 이상의 웹 모듈과 별도로 분리된 스프링 컨텍스트를 엔터프라이즈 어플리케이션으로 묶는 방법
• 백그라운드 서비스 모듈 : rar 로 리소스 커넥터를 만들어 배포하는 방식, UI 를 가질 필요 없고 백그라운드 서비스 처럼 사용되는 경우

다음은 스프링 어플리케이션에서 적용 가능한 아키텍처에 대해서 알아보려고 합니다.

먼저 아키텍처는 어떤 경계 안에 있는 내부 구성요소들이 어떤 책임을 갖고 어떤 방식으로 서로 관계를 맺고 동작하는지를 규정하는 것이라고 할 수 있고 저는 이를 어플리케이션의 뼈대와 같다고 생각하고 있습니다.

스프링에서는 크게 2가지 아키텍처를 제안하고 있습니다.

• 계층형 아키텍처 : 어플리케이션을 구성하는 오브젝트들을 비슷한 성격과 책임을 가진 것들로 묶어주는 방법

  • 3계층 아키텍처 : 3개의 계층을 가로선으로 각각의 책임으로 분리한 방식

    • 데이터 엑세스 계층

      DAO 계층이라고도 불리며 DB, ERP, 레거시 시스템 등에 접근하는 역할을 하는 계층으로 대게는 장기적인 데이터 저장을 목적으로 하는 DB 이용이 주된 책임을 가지는 계층 입니다.

    • 서비스 계층

      POJO로 만들어지는 비지니스 로직의 핵심을 담는 계층 다만 비지니스 로직을 담은 서비스 계층과 엔터프라이즈 서비스를 제공하는 기반 서비스 계층은 이름 때문에 혼동하기 쉬우니 주의가 필요합니다.

      기반 서비스 계층은 주로 트랜잭션, 보안, 리모팅, 메일, 메세징 등의 서비스를 제공합니다.

    • 프레젠테이션 계층

      HTTP 프로토콜을 주로 처리하는 엔터프라이즈 어플리케이션의 특성상 서블릿 기술이 바탕이 되어 다른 계층과 달리 클라이언트까지 그 범위가 확장 될 수 있는 계층으로 초기엔 클라이언트 영역을 처리 했지만 지금은 RIA 나 SOFEA 로 프레젠테이션 계층이 이동하고 있습니다.

      • RIA : HTML5, JS 를 통해 구성되는 아키텍처로 좀 넓은 범위
      • SOFEA : 프레젠테이션 계층에 해당하는 코드를 클라이언트로 완전히 넘어가 분리되는 형태입니다.

    이런 계층을 설계 할때 주의점으로는 각 계층이 자신의 역할과 책임에만 집중해야 하고, 다른 계층과는 인터페이스를 통해 최대한 특정 계층의 기술이 덜 드러나도록 구현해야 합니다.

  • 수직 계층

    • JDBCTemplate 처럼 로우레벨의 기반 계층에 존재하는 JDBC와 DB 드라이버, 스프링의 트랜잭션 추상화 서비스 등에 접근하는 계층으로 3계층과는 다르게 세로선의 추상 계층 입니다.

• 어플리케이션 정보 아키텍처 : 어플리케이션에 흘러다니는 정보를 어떻게 다룰지를 결정하는 아키텍처

  • 데이터 중심 설계 : 어플리케이션에 흘러다니는 정보를 단순히 값이나 값을 담기 위한 목적의 오브젝트 형태로 취급하는 방법

    • DB/SQL 중심의 로직 구현 방식 : DB 에서 돌려주는 내용을 그대로 맵이나 단순 결과 저장용 오브젝트에 넣어서 전달해 서비스 계층과 프레젠테이션 계층에서도 이를 사용합니다.
    • 하나의 기능 트랜잭션에 모든 계층의 코드가 종속되는 경향이 있습니다.
    • 자바 코드는 단순히 DB 와 웹 화면을 연결해주는 인터페이스 도구로만 사용
    • 거대한 서비스 계층 방식 : 상대적으로 단순한 DAO 로직을 사용하며 비지니스 로직의 대부분을 서비스 계층에 집중하는 방식입니다.
      • 비지니스 로직이 어플리케이션의 코드에 담기기 때문에 자바 코드를 활용해 로직을 구현해 테스트 하기 쉽고 자바 코드의 장점을 살릴 수 있습니다.

  • 오브젝트 중심 설계 : 도메인 모델을 반영하는 오브젝트 구조를 만들어 각 계층 사이에서 정보를 전송하는 방식

    • 도메인 오브젝트 : 도메인 모델의 구조를 반영해 만들어진 오브젝트로 어플리케이션의 전 계층에서 동일한 의미를 갖기에 SQL이나 웹 페이지의 출력 포맷, 입력 폼 등에 종속되지 않는 일관된 형식의 어플리케이션 정보를 다룰 수 있습니다. SQL은 아무래도 필요한 내용에 따라 별도의 SQL 을 계속 작성해서 필드 값을 가져와 Map 형태로 만들어서 사용됩니다. 다만 최적화된 SQL 을 사용하지 않기 때문에 성능면에서 이슈가 있습니다.

      다만 지연된 로딩 등을 사용하고 JPA나 하이버네이트 등 RDB 매핑 기술을 사용하면 좀 더 간단하게 사용할 수 있습니다.

    • 빈약한 도메인 오브젝트 방식 : 정보만 담겨 있고 정보를 활용하는 아무런 기능도 갖고 있지 않을 경우엔 빈약한 오브젝트라고 부릅니다.

      • 주된 비지니스 로지근 서비스 계층에 집둥 되기 때문에 어떻게보면 거대한 서비스 계층 방식의 하나라고 볼 수 있습니다.

    • 풍성한 도메인 오브젝트 방식 : 정보와 정보를 활용하는 비지니스 로직들이 담겨 있는 오브젝트 입니다.

      • 다만 어디서든 비지니스 로직에 접근 할 수 있기 때문에 사용에 주의해야 합니다.

    추가 주의점입니다.

    • 도메인에 종속적인 비지니스 로직의 처리는 도메인 오브젝트 내에서 진행하고 도메인 종속이 아닌 비지니스 로직은 서비스 계층에서 진행합니다.
    • 도메인 오브젝트가 기존 데이터 엑세스 계층이나 기반 계층의 기능을 직접 활용 할 수 있습니다. 다만 다른 빈을 이용할 경우엔 AspectJ AOP 를 사용해 빈으로 생성해줘야 합니다.
    • 도메인 오브젝트를 독립적인 계층으로 만들려고 할 때의 고려사항 입니다.
      • 모든 계층에서 사용하기 때문에 사용에 대한 개발 가이드라인을 적용합니다.
      • 도메인 오브젝트를 도메인 계층을 벗어나지 못하게 하고 DTO(Data Transfer Object) 를 사용해 상태 변화를 허용하지 않는 읽기 전용의 오브젝트를 사용해 각 계층으로 전달 합니다.

마지막으로 이렇게 스프링에 대해서 공부를 해보았는데 제가 자주 사용했던 레일즈 프레임워크에서나 프로그래밍을 하면서도 전체를 관통할 수 있는 지식을 알게 되어 좋은 스터디가 되었다고 생각합니다.