[Spring] 스프링 계층 구조의 이해

용어 정리

• DAO(Data Access Object) - DB를 사용해 데이터를 조회하거나 조작하는 기능을 전담하도록 만든 객체, Service와 DB를 연결하는 고리의 역할을 한다.
  
  
• BO(Business Object) -여러 DAO를 활용하여 비즈니스 로직을 처리하는 클래스, Service에 해당
  
  
• DTO(Data Transfer Object) - 계층 간 데이터 교환을 위한 객체, 데이터를 각 레이어 간에 전달하는 목적을 가지며 객체의 속성과 getter, setter만 가지고 있다. 하지만 보통 DB에서 꺼낸 값을 임의로 변경할 필요가 없기 때문에 DTO클래스에는 setter가 없다. 대신 생성자에서 값을 할당한다.
  
  
• VO(Value Object) - DTO와 동일한 개념이지만 read only 속성을 갖는다. VO는 특정한 비즈니스 값을 담는 객체이고, DTO는 Layer간의 통신 용도로 오고가는 객체를 말한다.
  
  
• POJO(Plain Old Java Object) - 특정 인터페이스나 클래스를 상속하지 않고, 순수하게 Getter, Setter로만 구성된 어디에도 종속되지 않은 자바 객체를 말한다. 종속되지 않는다는 것은 해당 클래스를 사용하기 위해 어떤 프레임워크나 외부 환경이 필요없다는 것이다.
  POJO를 사용하면, 특정 라이브러리나 컨테이너의 기술에 종속적이지 않고 가장 일반적인 형태로 코드를 작성할 수 있는데 이를 통해 코드에 대한 테스트 작업을 좀 더 유연하게 할 수 있다.
  
  
• Controller - Web MVC의 전체적인 컨트롤러 역할, 클라이언트로 부터 요청을 받고, 응답을 해주는 역할 담당
• Domain(Entity) - 비즈니스에 필요한 핵심 객체들, DB의 테이블과 1대 1 매칭될 수 있다.
• Service - 프레젠테이션(뷰)에서 엔티티에 직접 접근하지않고 비즈니스 로직을 처리할 수 있도록하는 계층, DAO로 DB에 접근하고 DTO로 데이터를 전달받은 다음, 비지니스 로직을 처리해 적절한 데이터를 반환한다.
• Repository(DAO) -  MVC 패턴에서 모델에 해당하는 부분으로 실제로 DB에 접근하는 객체이다. Service와 DB를 연결하는 고리의 역할을 한다. 

 

스프링 웹 계층

스프링 부트와 AWS로 혼자 구현하는 웹 서비스 참조

Web Layer

- Controller와 View 템플링 영역이다. 이 외에도 필터, 인터셉터, 컨트롤러 어드바이스 등 외부 요청과 응답에 대한 전반적인 영역을 의미한다. 

 

DTOs

- DTO들의 영역을 의미한다. 예를 들어, 뷰 템플릿 엔진에서 사용될 객체나 Respository Layer에서 결과로 념겨준 객체 등이 이들을 말한다.

 

Service Layer

- @Service에 사용되는 서비스 영역이다. 일반적으로 Controller와 DAO의 중간 영역에서 사용된다. @Transactional 이 사용되어야 하는 영역이기도 하다. 서비스에서는 트랜잭션과 도메인 간의 순서만 보장한다.

- Service Layer 작성 시 주의 사항

• Service는 다른 Service를 조합하거나 DAO를 연결하는 역할을 수행한다.
• Sevice는 가볍게! Service에 핵심 비즈니스 로직을 구현하기 보다는 로직의 상태값을 가지고 있는 모델이 담당해야 한다.
• Service에서 Service를 참조 가능하나 순환 참조를 방지하기 위해 계층 구조가 명확해야 한다.

 

Repository Layer

- DB와 같이 데이터 저장소에 접근하는 여역이다. DAO 영역이라고 생각하면 된다.

 

Domain Model

- 도메인이라 불리는 개발 대상을 모든 사람들이 동일한 관점에서 이해할 수 있고 공유할 수 있도록 단순화시킨 것을 도메인 모델이라 한다.

- 비즈니스 로직을 처리하는 영역이다. 예를 들어 택시 앱이라 하면 배차, 탑승, 요금 등이 모두 도메인이 될 수있다.

- @Entity 가 사용된 영역 역시 도메인 모델이라고 이해하면 된다. 다만 무조건 데이터베이스의 테이블과 관계가 있어야 하는 것은 아니다. VO 처럼 값 객체들도 이 영역에 해당한다.

 

스프링 프로젝트 구조

출처 : https://mangkyu.tistory.com/156

결론적으로 스프링 프로젝트는 다음과 같은 구조를 가지게 된다.

• Presentation Layer(프레젠테이션 계층): 웹 기반으로 요청과 응답을 처리하는 계층
• Service Layer(서비스 계층): 비지니스 로직을 담고있는 계층
• Data Access Layer(데이터 접근 계층): DB와 연동되어 데이터에 접근하는 계층

 

다시 한 번 정리해서 보자면,

Presentation Layer(프레젠테이션 계층)

클라이언트로부터 HTTP 요청을 수신하고 그에 맞는 응답을 돌려주는 계층

프레젠테이션 계층으로 명시하기 위해 사용되는 어노테이션들

• @Controller
• @RestController

 

요청을 수신하기 위해 Restful API에 맞는 Mapping 어노테이션들

• @GetMapping
• @PostMapping
• @PutMapping
• @DeleteMapping

 

Service Layer(서비스 계층)

요구 사항에 맞게 비지니스 로직을 작성하는 계층

서비스 계층으로 명시하기 위해서 쓰는 어노테이션

• @Service

 

트랜잭션에 대한 관리를 하기 위해 선언하는 어노테이션

• @Transactional

최근에는 도메인 중심의 개발을 하면서 핵심 비지니스 로직은 도메인 객체 또는 계층에 존재하며, 서비스 계층은 위임의 역할을 하거나 다른 도메인과 함께 처리되어야 하는 비지니스 로직이 많이 작성되기도 한다.

 

Data Access Layer(데이터 접근 계층)

데이터를 저장하거나 조회하기 위해 DB에 접근하는 계층

데이터 접근 계층으로 명시하기 위해 사용하는 어노테이션

• @Repository

다음 어노테이션을 명시하면 Spring은 @Repository가 붙은 것을 빈으로 등록하며, 추가적으로 에러 추상화와 같은 부가적인 기능을 제공한다.

 

계층의 역할/책임에 충실한 개발

 자신의 계층이 갖는 책임에만 충실하도록 개발해야 한다. 그렇지 않으면 유연성이 떨어지고 이해하기 힘든 구조를 갖게 될 것이다.

 

 

Reference - https://mangkyu.tistory.com/156, https://blog.naver.com/ghdalswl77/222489613651