9. 스프링부트와 AWS - 트랜잭션 스크립트, 도메인 모델

JPA를 설정했다면 이제 게시판에 쓸 게시글 등록, 수정, 조회를 위한 API를 만들 차례다.

API 만들기 전 알아둘 것

API를 만들기 위해 필요한 클래스는 총 3개다.

 

- Request한 데이터를 받을 Dto

- API 요청을 받을 Controller

- 트랜잭션, 도메인 기능 간의 순서를 보장하는 Service

 

위의 내용을 보면 비즈니스 로직에 대한 부분이 없는 것을 알 수 있다.

 

이것에 대해 이해를 하려면 내용이 기니까 여기서 짚고 넘어가보자.

 

위 그림은 책에 나와있는 그림으로 Spring Web 계층에 대해 설명하는 그림이다.

 

책에서는 위 그림을 예시로 들며 우리가 흔히 Service에서 비즈니스 로직을 처리하는 것으로 오해한다고 쓰여있다.

 

실제로 국비 지원 과정서에서 비즈니스 로직을 서비스 레이어에서 구현한다고 배우기도 한다.

 

하지만 저자는 실제 비즈니스 로직은 Domain 과정에서 이뤄진다고 설명한다.

 

즉 서비스 레이어는 이러한 도메인에 대한 트랜잭션과 순서만 정의할 뿐이다.

 

그리고 비즈니스 로직은 도메인에서 별도로 이뤄진다는 것이다.

 

근데 사실 이 부분에 대한 이해가 쉽지 않았다.

 

그냥 문자 그대로 이해하고 넘어가도 되지만 책의 코드도 그렇고 머리에 쉽게 들어오지 않았다.

 

그래서 웹서핑을 하다보니 아래의 자료를 찾았다.

스프링 웹 어플리케이션 구조에 관한 이해

Understanding Spring Web Application Architecture: The Classic Way

 

해당 링크는 해외 사이트에 올라온 글인데 저자가 인용한 그림에 대한 설명이 있는 글이다.

 

스프링 웹 아키텍처에 관한 글로서 대충 설명하면 다음과 같다.

 

클래식한 관점에서 스프링 웹 아키텍처는 관심사에 따라 3개의 레이어로 나뉜다.

 

각 레이어는 다음과 같은 역할을 한다.

 

- Web Layer:

해당 어플의 최상위 레이어로서 사용자 입력을 처리하고 이에 따른 응답을 반환을 하는 역할

 

- Service Layer:

Web Layer 하단의 레이어로서 트랜잭션간 경계역할, 애플리케이션의 다양한 서비스를 처리하는 역할

 

- Repository Layer:

가장 하단의 레이어로서 데이터 베이스와 관련된 업무를 처리하는 역할

 

그리고 이러한 레이어 사이에서 데이터를 처리하고 이동시켜주는 인터페이스가 필요하다.

 

그것이 바로 DTO와 Domain이다.

 

웹 레이어는 DTO만 처리해야하고 서비스 레이어는 DTO를 매개변수로 받고 Domain을 처리가능하다.

 

단, 서비스 레이어에서 웹 레이어로의 반환은 DTO만 가능하다.

 

그리고 서비스 레이어와 리포지토리 레이어 간은 도메인을 통해 데이터를 처리한다.

 

근데 그림만 봐도 이해가 안가서 글을 찾아봤는데 여전히 이해가 쉽지 않았다.

 

각종 로직은 레이어에서 처리하는 건데 어떻게 도메인에서 처리한다는건지 이해가 어려웠다.

 

그래서 책에 있는 내용을 기반으로 영상 하나를 찾았는데 그게 바로 아래의 영상이다.

트랜잭션 스크립트와 도메인 모델

해당 영상은 객체지향적으로 코드 설계시 애플리케이션의 아키텍처가 어떻게 변화되는지에 관한 영상이다.

 

1시간 20분짜리 영상인데 강의 내용이 어렵지 않지만 그마저 어려울 수 있으므로 풀어쓰면 다음과 같다.

 

흔히 소프트웨어를 개발할 때 아키텍처라는 말을 하게 된다.

 

간단히 말하면 아키텍처란 소프트웨어를 어떻게 구성할 것인지에 대한 이야기같은 것이다.

 

그리고 우리가 흔히 애플리케이션 개발시 많이 사용하는 아키텍처가 바로 레이어 아키텍처다.

 

레이어 아키텍처는 유사한 관심사들을 모아서 층을 분리하고 수직적으로 배열한 것이다.

 

그림으로 보면 아래와 같다.

 

 

물론 어플리케이션마다 레이어의 구조는 조금씩 다를 수 있다.

 

하지만 일반적으로는 위와 같이 크게 세 부분으로 나뉜다.

 

- Presentation: 화면 조작, 사용자 입력 처리를 위한 관심사

- Domain: 비즈니스와 관련된 도메인 로직 처리

- DataSource: 데이터를 제어하는 것과 관련된 레이어

 

이 중에서 가장 중요한 레이어는 바로 Domain 레이어라고 할 수 있다.

 

그 이유는 다른 애플리케이션과 가장 차별화될 수 있으며 비즈니스 로직을 이 곳에서 처리하기 때문이다.

 

그리고 이 도메인 레이어를 설계하는 방법은 크게 둘로 나뉜다.

 

- 절차 지향: 트랜잭션 스크립트 패턴

- 객체 지향: 도메인 모델 패턴

 

흔히 우리가 사용하는 방식은 절차지향적 즉 트랜잭션 스트립트다.

 

간단히 설명하면 우리가 지금까지 짜온 코드들의 작동 과정을 보면 아래와 같다.

 

1. 고객이 프레젠테이션 레이어에 요청을 한다.

2. 도메인 레이어에서 데이터를 불러온다.

3. 도메인 레이어에서 데이터를 조작한다

4. 도메인 레이어에서 데이터를 반환한다.

5. 프레젠테이션 레이어를 통해 고객에게 데이터가 반환된다.

 

즉 데이터는 데이터대로 놀고 데이터를 처리하는 프로세스는 따로 노는 상황이다.

 

데이터는 프로세스와 전혀 상관없이 움직이고 있는 상황이다.

 

그리고 도메인 레이어에서 이 모든 과정이 한번에 이뤄진다.

 

보통 MVC패턴으로 배울 때 서비스 클래스 내에서 이런 과정이 이뤄지는 것을 볼 수 있다.

 

이러한 방식이 나쁜건 아니다.

 

절차지향적인 설계는 상대적으로 구현하기가 쉽고 변화가 크지 않은 코드에선 큰 무리가 없다.

 

반면 객체지향적인 도메인 모델은 다음과 같다.

 

1. 고객이 어떤 요청을 한다

2. 서비스 레이어에서 고객이 요청, 정보를 도메인 레이어에 있는 각자 역할을 수행하는 객체에 전달한다.

3. 도메인 레이어에 위치한 정보를 객체들은 자기가 맡은 역할을 내부적으로 수행한다.

4. 수행한 결과를 서비스 레이어에 데이터를 반환한다.

5. 고객에게 데이터가 반환된다.

 

도메인 모델의 가장 큰 특징은 각각의 객체가 책임을 가지고 요청을 처리한다는 것이다.

 

트랜잭션 스크립트는 도메인 레이어에서 정보를 불러와서 레이어 내부에서 처리한다.

 

반면 도메인 모델은 데이터 별로 객체가 존재하고 해당 객체가 내부에서 데이터를 처리한다.

 

그렇기 때문에 도메인 레이어 하나만으로는 작동할 수 없다.

 

데이터를 객체에 전달해주고 전달 받아서 반환하는 등의 후처리가 필요하다.

 

그래서 이때 필요한 것이 바로 서비스 레이어다.

 

 

도메인 모델을 이용하게 될 경우 최종적으로 기본 레이어 아키텍처에서 약간의 변경이 된다.

 

반면 앞서 말했듯 트랜잭션 스크립트는 도메인 레이어 내부에서 모든 로직이 수행된다.

 

그러므로 별도의 Service레이어가 필요없게 되고 Service를 만들순 있어도 그 의미가 없게 된다.

 

반면 도메인 모델은 각 데이터를 담당하는 객체들이 존재하고 이 객체는 Domain에 위치한다.

 

그리고 Service에서 객체의 데이터를 주고 받을 수 있는 역할을 하기 때문에 Service가 필요해진다.

 

이러한 관점에서 객체 지향 설계를 하면 비즈니스 로직은 도메인에서 이뤄진다는 것이다.

 

뭐 내가 잘 몰라서 그럴 수 있는데 첫번째 링크의 글과 영상의 강의를 보고나면 해당 책에 있는 그림인 위의 스프링 웹 계층과 도메인 모델이 이 내용을 이해하기엔 완벽하지 않다는 느낌이 든다.

 

물론 앞서 말한대로 이걸 책에서 다 설명했다면 아마 내용이 산으로 갔을 것이다.

 

하지만 이렇게라도 무리하게 설명한건 다 이유가 있는 것 같다.

 

해당 저자는 이 프로젝트의 구조와 코드를 모두 객체지향적으로 표현하고 싶었던 것 같다.

 

그렇다보니 우선 데이터 베이스를 JPA를 통해 객체지향적으로 다뤘다.

 

하지만 이 뿐만 아니라 애플리케이션의 코드와 구조도 객체지향적으로 다뤄야 한다.

 

그렇기 때문에 무리해서라도 객체지향적인 구조를 짤 수 있는 도메인 모델에 대해 설명한 것 같다.

 

근데 이거 다 쓰고 나니 생각난건데...myBatis로도 객체지향적으로 짤 수 있지 않나 싶다.

 

다만 아직 다양한 예제를 본 적이 없고 배움이 짧아서 앞으로 이 부분은 더 공부해야겠단 생각이 들었다.