Published on
•
👁️

SpringBoot 계층 구조

Authors
  • avatar
    Name
    River
    Twitter

계층 구조

계층 구조(Layered Architecture)란

  • 기본적으로 프레임워크를 사용해서 API 서버를 만들 때

    ⇒   해당 프레임워크 구조를 지키며 만들어야 한다.   (협업의 문제)

  • 계층 구조의 핵심   :   "관심사 분리" ⇒   즉, "내가 담당하는 업무만 신경 쓰고 다른 부분은 다른 계층이 담당한다"



SpringBoot + Mybatis의 계층 구조     (MVC + Service + DAO 아키텍처)

SpringBoot 계층 구조
  • Controller Layer   (Controller)
  • Service Layer   (Service)
  • Persistence Layer   (DAO)
  • Model   (VO)
  • Database Layer   (ex. MySQL)

  • 대표적인 계층 구조의 예시로 ⭐ MVC + Service + DAO 아키텍처 ⭐라 한다.

  • ⭐나의 코드 ⭐
    • 위의 그림은 내가 구상한 벡엔드에서 Layer 구조이다.
    • DTO와 VO를 혼용하였다.
      • 비즈니스 로직이 복잡하다고 판단했고, DB 테이블을 VO로 반환하고 이를 서비스단에서 DTO로 전환시키는 방법을 사용하였다.
      • 현재 VO는 비즈니스 로직이 없는 그냥 데이터 전달 용도로만 사용되고 있다.
      • 따라서, 거의 DTO와 유사하게 사용되고 있으므로 VO 없이 DTO만 사용하도록 바꿀 예정이다.

  • ⭐현업 ⭐
    • 이렇게 VO를 단순한 데이터 전달 용도로 사용하는 경우 DTO로 쓰이고 있다고 볼 수도 있다.
      • 원래는 구분하여 사용하는 것이 이상적이지만, 대부분 그냥 사용한다.
    • 많은 현업에서는 VO와 DTO를 혼용하지 않고 DTO만 사용하여 데이터를 처리한다.


각 계층의 역할

  • Controller Layer     (Web Layer, Presentation Layer)
    • 클라이언트 요청 처리   (HTTP 요청 처리)
    • 인증 로직 처리
    • Validation 라이브러리

  • Service Layer     (Business Layer)
    • @Service
    • 비즈니스 로직 처리
      • Presentation Layer에서 전달 받은 데이터를 유효성 검사
      • 비즈니스 로직을 이곳에서 처리하지 않는다면 DDD 방식일 수 있다.
    • 트랜잭션 적용 영역 (@Transactional)
    • Controller와 Dao의 중간 영역

  • Persistence Layer     (지속성 계층)
    • DAO (Mybatis)   /   Repository (JPA) - Mybatis - SQL 기반 ORM 프레임워크 - 데이터베이스와의 연결은 JDBC 드라이버를 통해 이루어지며, 사용하는 DBMS에 따라 Mapper 파일의 SQL 문법만 달라질 수 있다. - DAO (@Mapper) - MyBatis Mapper 파일 (.xml)
    • Database와 같이 데이터 저장소에 접근하는 영역   (= Dao(Data Access Object) 영역) - 데이터베이스에 대한 논리 모델을 나타낸다.
    • 데이터베이스와 상호작용
      • 비즈니스 로직에서 생성된 개체를 데이터베이스 개체로 변환
      • 데이터 저장, 조회, 갱신, 삭제

  • Domain Layer
    • 도메인 객체   :   VO, Entity
    • Domain Layer은 비즈니스 로직을 가진 Domain 객체가 존재할 때 사용하는 개념
    • SpringBoot + Mybatis의 경우
      • VO는 단순히 데이터 전달 객체로 쓰이므로 Domain Layer는 없다고 볼 수 있다.
      • 이 경우 VO는 Model이라 많이 한다.
    • MVC 패턴에서는 Domain 객체라는 용어를 사용하지 않고 Model 이라는 용어로 다룬다.
      • MVC에서의 Model은 비즈니스 로직을 포함할 수도 있고, 단순한 데이터를 표현하는 객체일 수도 있다
      • Domain 객체를 사용하고 있다면 Model이 곧 Domain 객체가 된다. 단, 비즈니스 로직이 서비스 계층에만 있고 Model이 단순 데이터 구조로만 사용된다면 Model은 더 이상 Domain 객체가 아니게 됩니다.

  • Database Layer
    • 실제 DBMS(ex. MySQL 서버)와 물리적인 데이터베이스 파일이 있는 외부 환경

  • DTO (Data Transfer Object)
    • 특정 계층에 소속되지 않는다.
    • 데이터 교환을 위한 객체   (계층 간 데이터를 주고 받을 때 사용)


(그 외)   DDD 방식

  • Domain-Driven Design 방식 - Domain 객체가 비즈니스 로직의 중심이 되어야 한다는 방식 - 서비스 계층(Service Layer)은 단순히 도메인 객체의 메서드를 호출하고 트랜잭션을 관리하는 역할 - Service Layer에서 Persistence Layer를 호출하여 DB의 데이터를 Domain 객체로 받아오고 이 Domain 객체에서 비즈니스 로직 처리까지 하는 방법
  • 비즈니스 로직을 도메인에 넣는 이유
    • 기존에 Service로 비즈니스 로직을 처리하던 방식은 트랜잭션 스크립트라고 한다. 모든 로직이 서비스 클래스 내부에서 처리하면 서비스 계층이 무의미하며, 객체란 단순히 데이터 덩어리 역할만 하게 된다.
    • 서비스 메소드는 트랜잭션과 도메인 간의 순서만 보장 (각각의 도메인이 본인의 이벤트 처리)

  • 그러나, Domain 객체에 비즈니스 로직을 넣으면 복잡해질 수 있다.   (즉, 유지보수가 힘들어진다)


VO과 Entity

  • VO
    • Mybatis 사용 시 VO를 사용한다.
    • MyBatis에서는 VO를 주로 사용하며, 데이터를 DB 테이블의 컬럼과 매핑하고 그 값을 VO로 반환
      • VO는 DB 테이블에서 데이터를 가져오거나, 클라이언트에 반환할 데이터를 저장하는 객체로 사용
      • 즉, MyBatis를 사용할 때는 VO를 데이터 전송 및 조회 용도로 사용
        • 비즈니스 로직을 처리하려면 서비스 계층에서 로직을 처리하거나,
        • 도메인 객체를 설계하여 해당 로직을 캡슐화하는 방식으로 설계할 수 있다.
    • JPA에서는 Entity가 필요하지만, MyBatis에서는 Entity 대신 VO만 사용해도 된다. 그러나 비즈니스 로직이나 객체 간의 관계가 복잡한 경우, VO만으로 처리하는 것보다는 Entity와 Domain 모델을 함께 사용하는 것이 더 적합할 수 있다.

  • Entity
    • JPA 사용 시 Entity를 DB 테이블과 매핑시킨다.
Discuss on Twitter • View on GitHub