[Spring]9_3 Application Architecture

Application Architecture

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

1) 계층형 아키텍처

- 인터페이스와 같은 유연한 경계를 만들어두고 분리하거나 모아주는 작업이 필요하다.

(1) 아키텍처와 SoC

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

- 웹 기반의 엔터프라이즈는 흔히 3계층 애플리케이션이라고함 

(2) 3계층 아키텍처와 수직 계층

- 3계층 아키텍처 : 데이터엑세스 계층, 서비스 계층, 프레젠테이션 계층

a. 데이터 엑세스 계층

- DAO 계층으로 불린다.

- 사용 기술에 따라 다시 세분화된 계층으로 구분

- 추상화 수준에 따른 구분으로 수직적인 계층이라고도 함

- ex) JdbcTemplate을 사용하는 DAO 계층

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

b. 서비스 계층

- DAO 계층을 호출하고 이를 활용해서 만들어진다.

- 데이터 엑세스를 위한 기능 외에 서버나 시스템 레벨에서 제공하는 기반 서비스를 활용할 필요도 있다.

- 추상화 수직 계층구조가 필요없다.

- 서비스 계층 코드가 기반 서비스계층의 구현에 종속되면 안된다.

- 백엔드, 데이터 엑세스 계층이 변경되더라도 그대로 유지되야함

c. 프레젠테이션 계층

- 가장 복잡하다. 다양한 기술과 프레임워크의 조화

- HTTP프로토콜을 처리하는 가장 기본 엔진 서블릿 기술을 바탕으로 한다.

(3) 계층형 아키텍처 설계의 원칙

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

a. 계층간의 설계 실수_1(서비스 계층에서 DAO호출시)

수정 전

public ResultSet findUsersByName(String name) throws SQLException;

- 데이터 엑세스 계층의 기술과 그역할을 다른 계층에 노출한다는 점

- 결과를 JDBC의 ResultSet으로 받음 -> 서비스 계층의 코드는 ResultSet이라는 데이터 엑세스 계층에서 만들어진 오브젝트를 직접 다뤄야함

- SQLException 이라는 JDBC기술 종속적인 예외를 사용하면 서비스계층에서는 SQLException을 해석해서 예외상황을 분석해야함

수정 후

public List<User> findUsersByName(String name) throws DataAccessException;

- 특정 계층에 종속되지 않는 단순한 오브젝트(User)의 형태로 전달해야함

- DataAccessException처럼 런타임 예외로 만듬 -> 그 존재를 무시할수 있도록

b. 계층간의 설계 실수_1(프레젠테이션 계층의 오브젝트를 그대로 서비스 계층의 전달)

- 서블릿의 HttpServletRequest, HttpServletResponse, HttpSession 같은 타입을 서비스 계층 인터페이스 메소드의 파라미터 타입으로 사용하면 안됨

- 계층의 경계를 넘어갈때는 반드시 특정 계층에 종속되지 않는 오브젝트 형태로 변환해야함

- 계층 사이의 낮은 결합도를 유지하며 계층사이의 호출은 인터페이스를 통해서만 이뤄져야 한다.

- 인터페이스를 사용한다는건? -> 각 계층의 경계를 넘어서 들어오는 요청을 명확히 하겠다는 뜻

- 한 계층의 내부에서만 쓰는 빈 오브젝트를 DI를 통해 다른 계층에서 함부로 쓰는 일을 피해야함

2)  애플리케이션 정보 아키텍처

- 엔터프라이즈 시스템은 동시에 많은 작업이 빠르게 수행됨

- 사용자의 요청을 처리하는 동안만 간단한 상태를 유지함

- 상태 정보 장기간보관: DB, 메인프레임 같은 EIS 백엔드 시스템에 저장

- 상태 정보 임시보관 : 클라이언트, 서버의 사용자별 세션

- 애플리케이션을 사이에 두고 흘러다니는 정보를 어떤 식으로 다룰지를 결정 하는 일도 아키텍처를 결정할때 중요한 기준이 됨

a. 정보를 데이터로 다루는 경우

- 애플리케이션에 흘러다니는 정보를 단수히 값이나 값을 담기위한 목적의 오브젝트 형태 취급

- 값을 그래도 프레젠테이션 계층, 즉 사용가자 보는 화면과 연결

- 핵심 비즈니스 로직을 어디에 두는지에 따라 DB에 무게를 두는 구조, 서비스 계층의 코드에 무게를 두는 구조로 나뉨

b. 정보를 오브젝트로 다루는 경우

(1) DB/SQL 중심의 로직 구현방식

- 데이터 중심 구조의 특징은 하나의 업무 트랜잭션에 모든 계층의 코드가 종속됨

a.단점

- 종속적이고 배타적이다, 다른 업무에 재사용하기 힘들다

- 업무의 내용이 바뀌면 모든 계층의 코드가 함께 변경된다

- SQL로직이 복잡해 질수 있다. 대부분의 코드가 중복되기 쉽다. 

- 서비스 계층이 의미가 없고 2계층 구조에서도 사용 가능

- 자바코드가 단지 DB와 웹 화면을 연결해주는 단순한 인터페이스 도구로 전락

b. 장점

- 개발이 쉽다.

- 툴이나 코드 생성기를 이용해 자동화 하기 쉽다.

- 개발자들 끼리 서로 간섭없이 자신에게 할당된 기능을 독립적으로 만드는데 편하다

(2) 거대한 서비스 계층(fat service layer)

- DB에 많은 로직을 두는 개발 방법을 피함

- 비즈니스 로직은 서비스 계층으로 옹겨와서 코드의 비중이 커지고 객체지향 개발의 장점을 살릴 수 있다. 

- SQL은 서비스 계층의 비즈니스 로직의 필요에 따라 만들어 지기 쉽다.

- 스파게티 코드가 될 수 있다.  중복발생과 장기적 코드 관리 힘들 수 있다.

3) 오브젝트 중심 아키텍처

- 도메인 모델을 방영하는 오브젝트 구조를 만들어두고 그것을 각 계층 사이에서 정보를 전송하는데 사용한다는 것이다. 

- 오브젝트를 만들어두고 오브젝트 구조 안에 정보를 담아서 각 계층 사이에 전달하게 만드는 것이 오브젝트 중심 아키텍처이다.

(1). 데이터와 오브젝트 비교

a. 데이터 방식 

- DAO가 만드는 SQL의 결과에 모든 계층의 코드가 의존하게 된다.

- Category와 그에 대응되는 Product를 찾아 SQL을 이용해 조인한후 하나의 맵에 뭉뚱그려 가져옴

b. 오브젝트 방식

- 애플리케이션에 사용되는 정보가 도메인 모델의 구조를 반영해서 만들어진 오브젝트 안에 담긴다. 도메인 모델은 애플리케이션 전 계층에서 동일한 의미를 갖는다.

- DB에서 SQL 결과로 가져온 값을 그대로 사용하는 경우와는 다르게, 도메인 모데을 반영하는 오브젝트를 사용하면 자바의 특성을 살릴 수 있다.

- 테이블의 정보와 그 관계를 유지한채로 정확한 개수의 Category오브젝트와 그에 대응하는 Product오브젝틀 만들어 사용

- DB에 가져온 정보를 도메인 오브젝트 구조에 맞게 변환해야함

- DAO, 서비스 계층은 자신이 DB에서 가져와서 도메인 모델 오브젝트에 담아주는 정보가 어떤 업무 트랜잭션에서 어떻게 사용될지 신경 안써도됨

(2). 도메인 오브젝트를 사용하는 코드

- 오브젝트 중심 방식의 비즈니스 로직 예

- 만약 데이터 중심이였다면 이런 식의 재사용 가능한 메소드를 만드는게 쉽지 않다.

(3). 도메인 오브젝트 사용의 문제점

- 성능면에서 데이터 방식 보다 떨어질 수 있다.

- DAO는 비즈니스 로직의 사용방식을 알지 못하므로, 도메인 오브젝트의 모든 필드 값을 다 채워서 전달 해야함(안쓰는 오브젝트 낭비 발생)

- ORM과 같은 데이터 액세스 기술을 사용하는 것을 권장한다.

- JDBC를 사용한다면 지연된로딩(lazy loading)기법을 사용

(4). 빈약한 도메인 오브젝트 방식

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

- 흔히 사용하는 방식중 하나

- 빈약한 오브젝트 방식에서는 비즈니스 로직이 서비스 계층에 존재한다.

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

- SQL에 의존적인 데이터 방식보다는 휠씬 유연하고 간결하다

- 서비스 계층의 메소드에 대부분의 비즈니스 로직이 들어 있기 때문에 로직의 재사용성이 떨어 지고 중복 발생이 쉽다.  

- 비즈니스 로직이 복잡하지 않다면 아주 유용한 방법

(5). 풍성한 도메인 오브젝트(rich domain object), smart domain object

- 빈약한 도메인 오브젝트의 단점을 극복하고 객체지향적인 특징을 살림

- 어떤 비즈니스 로직은 측정 도메인 오브젝트나 그 관련 오브젝트가 가진 정보과 깊은 관게가 있고 이런 로직을 서비스 계층의 코드가 아니라 도메인 오브젝트에 넣고 서비스 계층의 비즈니스 로직에서 재사용( 응집도를 높임)

- 훨씬 간결하고 객체지향적이다 .

- 스프링의 빈으로 관리되는 3계층의 오브젝트들은 도메인 오브젝트를 자유롭게 이용할 수 있지만 그 반대는 안 됨

- 시스템이 복잡할때 적합

(6). 도메인 계층 방식

- DB에서 가져와 변경된 정보를 다시 DB에 반영하려면 서비스 계층 오브젝트의 부가적인 작업이 필요

- 3계층의 오브젝트를 DI 받아서 직접 사용??? 가능?? -> 도메인 계층 방식 등장

- 기존 3계층과 같은 레벨로 격상된다. 서비스 계층과 데이터 액세스 계층의 사이에 존재

- 도메인에 종속적인 비즈니스 로직의 처리는 서비스 계층이 아니라 도메인 계층의 오브젝트 안에서 진행

- 도메인 오브젝트가 기존 데이터 액세스 계층이나 기반 계층의 기능을 직접 활용? ->

-> 스프링이 관리하지 않는 도메인 오브젝트에 DI를 적용하기 위해 AOP가 필요

- 도메인 계층사용시 선택 방법

- 여전히 모든 계층에서 도메인 오브젝트를 사용하게 한다.

-> 주의 안하면 심각한 혼란을 초래

- 도메인 오브젝트는 도메인 계층을 벗어나지 못하게 하는것

->  안전하지만 번거로울 수 있다.

- 매우 복잡하고 변경이 잦은 도메인을 가졌을 때 사용 권장

The Source of post is Spring of Toby3