[F-Lab 챌린지 47일차 TIL]

스프링 어플리케이션에 적용할 수 있는 아키텍처 종류와 특징

1. 계층형 아키텍처

• 어플리케이션을 구성하는 오브젝트들은 유사한 성격을 띤 그룹으로 나눌 수 있다.

• 성격이 다른 것은 아키텍처 레벨에서 분리해주는 게 좋다.

• 분리의 장점

  • 독자적 개발, 테스트가 가능하다.
  • 변경시 계층간 서로 영향을 주지 않고 변경될 수 있을 만큼 유연하다.

• 책임과 성격이 다른 것을 크게 그룹으로 만들어 분리해두는 것을 아키텍처 차원에서는 계층형 아키텍처라고 부른다.

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

• 3계층 아키텍처와 수직 계층

  

  • 각 계층 내부에서 추상화 정도에 따라 다시 수직적 계층이 형성될 수 있다.
  • 데이터 엑세스 계층 DAO 계층이라고도 하며 DB 사용이 주된 책임이다.
    
  • 서비스 계층
    • 서비스 계층 클래스는 이상적인 POJO로 작성된다.
    • 도메인의 핵심 비즈니스 로직이 들어 있는 서비스 계층이다.
    • 비즈니스 로직을 담은 서비스 계층과 엔터프라이즈 서비스를 제공하는 기반 서비스 계층은 이름 때문에 혼동되기 쉬우므로 주의하자.
    • 서비스 계층의 코드는 추상화된 기반 서비스 인터페이스를 통해서만 접근하도록 만들어서 특정 구현과 기술에 대한 종속성을 제거해야 한다.
  • 프레젠테이션 계층
    • 자바에서 HTTP 프로토콜을 처리하는 가장 기본 엔진이 서블릿 기술을 바탕으로 한다.

• 계층형 아키텍처의 설계 원칙

  • 각 계층은 자신의 계층의 책임에만 충실해야 한다.
  • 어떤 경우에라도 계층 사이의 낮은 결합도를 깨뜨리지 않도록 설계해야 한다.
  • DI 는 계층을 구분해주지 않기 때문에 빈 사이의 의존관계를 만들 때 주의해야 한다.
    한 계층의 내부에서만 사용되도록 만든 빈 오브젝트가 있는데, 이를 DI를 통해 다른 계층에서 함부로 가져다 쓰는 일은 피해야 한다.

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

엔터프라이즈 애플리케이션은 일반적으로 사용자 요청을 처리하는 동안만 간단한 상태를 유지한다.
어플리케이션을 사이에 두고 흘러다니는 정보를 어떤 식으로 다룰지를 결정하는 일도 아키텍처를 결정할 때 매우 중요한 기준이 된다.

• 애플리케이션에 존재하는 정보 구분

  1. 데이터로 다루는 경우
  2. 오브젝트로 다루는 경우

• 데이터 중심 아키텍처

  • 에플리케이션에 플러다니는 정보를 단순히 값이나 값을 담기 위한 목적의 오브젝트 형태로 취급하는 구조
  • 구분
    1. 핵심 비즈니스 로직을 DB에 무게를 두는 구조
    2. 서비스 계층의 코드에 무게를 두는 구조
  • 핵심 비즈니스 로직을 DB에 무게를 두는 구조
    • 하나의 업무 트랜잭션에 모든 계층의 코드가 맞춰서 돌아간다.
    • 자바 코드를 단지 DB와 웹 화면을 연결해주는 단순한 인터페이스 도구로 전락시킨다.
    • 오브젝트는 단순한 포맷의 데이터다
    • 이 오브젝트가 계층간 접착제 역할을 해서 강한 결합을 만들게 된다.
  • 거대한 서비스 계층 방식
    • 오브젝트 목적은 단순한 데이터 전달로 같지만 DB에 많은 로직을 두는 개발 방법의 단점을 피하면서 애플리케이션 코드의 비중을 높이는 방법이다.
    • 애플리케이션 코드의 비중이 커진다.
    • 장점은 비즈니스 로직을 자바 언어의 장점을 활용해 구현할 수 있고 재사용, 테스트 수월하다.
    • 단점은 객체지향 원칙을 못지키면 스파게티 코드가 된다.

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

• 도메인 모델을 반영하는 오브젝트 구조를 만들어두고 그것을 각 계층 사이에서 정보를 전송하는 데 사용한다는 것.
• 데이터 중심 아키텍처에서는 DAO 가 만드는 SQL 결과에 모든 계층의 코드가 의존하지만, 도메인 모델은 애플리케이션 전 계층에서 동일한 의미를 갖는다.
• 오브젝트에 비즈니스 로직을 담는다.
• 단점
  • DAO 가 비즈니스 로직을 담당하지 않으므로 도메인 오브젝트가 모든 필드를 채워 다녀야하는 경향이 있기 때문에 성능 면에서 조금 손해을 볼 수 있다.
• 지연된 로딩을 사용해서 도메인 오브젝트 생성을 최적화할 수 있다.
• 그래서 오브젝트 중심 아키텍처에서는 가능하다면 ORM 과 같은 오브젝트 중심의 데이터 엑세스 기술을 사용하는 것을 권장한다.

오브젝트 활용 방법에 따른 구분

1. 빈약한 도메인 오브젝트
   • 도메인 오브젝트에 정보만 담겨 있고, 정보를 활용하는 아무런 기능도 갖고 있지 않다.
     하지만 계층 사이의 독립성 확보는 보장한다.
   • 빈약한 도메인 오브젝트의 비즈니스 로직은 서비스 계층에 존재한다.
   • 다루는 정보의 구조가 다를 뿐이지 빈약한 도메인 오브젝트 방식은 데이터 중심 아키텍처의 거대 서비스 계층구조와 비슷하다.
   • 한계
     • 거대 서비스 계층 방식의 한계와 비슷하다. 로직의 재사용성이 떨어지고 중복의 문제가 발생하기 쉽다.
2. 풍부한 도메인 오브젝트
   • 도메인 오브젝트의 객체지향적인 특징을 잘 사용할 수 있도록 개선한 것이다.
   • 특정 도메인 오브젝트가 가진 정보와 밀접한 로직을 서비스 계층이 아닌 도메인 오브젝트에 둔다.
   • 응집도가 높아진다.
   • 빈약한 도메인 오브젝트 방식 보다 서비스 계층의 코드가 간결하다.
   • 도메인 오브젝트가 스스로 처리 간으한 기능과 도메인 비즈니스 로직을 갖도록 만드는 것이 바람직하다.
   • 단점
     • 충실한 도메인 모델링과 개발자에게 충분히 공유되어야 한다. 그래야 혼란을 방지한다.

• 도메인 계층 방식
  • 도메인 오브젝트 스스로가 필요한 정보를 DAO 를 통해 가져오고 반영하는 계층을 따로 두는 방식이다.
  • 도메인을 기존 3계층과 같은 레벨로 격상시켜 하나의 계층을 이루게 하는 도메인 계층 방식이다.
  • 서비스 계층과 데이터 엑세스 계층 사이에 존재하게 한다.
  • 특징
    • 비즈니스 로직 처리는 서비스 계층이 아니라 도메인 계층의 오브젝트 안에서 진행된다.
    • 도메인 오브젝트가 기존 데이터 엑세스 계층이나 기반 계층의 기능을 직접 활용한다.
    • 도메인 계층이 다른 빈을 활용하기 위해서는 AOP 가 필요하다.
  • 매우 복잡하고 변경이 잦은 도메인을 가졌을때 사용하면 좋다.