You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
프런트에서 api 요청이 들어오게 되면 내장 톰켓이 요청과 매치되는 컨트롤러 단의 메소드를 찾아 요청을 보내줍니다.
이후 컨트롤러는 서비스 단의 적절한 서비스 메서드를 호출하고 본격적으로 비지니스 로직을 시작합니다.
서비스에서는 디비 정보를 가져오기 위해 필요한 레포지토리를 사용합니다.
레포지토리에서 특정 메서드가 실행되면 이때 실질적인 디비 쿼리가 날아가고 리턴값으로 원하는 데이터를 받아올 수 있게 됩니다. (삽입, 수정, 삭제의 경우에는 리턴값이 없을 수도 있음)
중간에 exception 이 발생하면 exceptionHandler 가 예외를 잡아 처리하고 api 에 에러 응답을 줍니다.
entity, dto, vo
Entity
정의: 데이터베이스와 직접적으로 매핑되는 클래스. JPA를 사용할 때 @entity 어노테이션으로 정의되며, 데이터베이스의 테이블 구조를 나타냅니다.
특징:
데이터베이스와 1:1로 매핑됩니다.
영속성 컨텍스트(Persistence Context)에 의해 관리되며, 데이터베이스 연산을 직접 처리합니다.
복잡한 비즈니스 로직이 포함되지 않도록 설계해야 합니다.
사용 사례:
데이터베이스와 관련된 CRUD 작업 수행.
Repository에서 직접 다루는 객체.
Entity는 애플리케이션 내부에서 사용하는 DTO로 변환되어야 합니다.
DTO (Data Transfer Object)
정의: 계층 간 데이터 교환을 목적으로 설계된 객체. 일반적으로 컨트롤러와 서비스, 서비스와 외부 시스템 간 데이터를 전달하는 데 사용됩니다.
특징:
읽기/쓰기 가능: 필요한 데이터를 담기 위해 가변적인 속성을 가질 수 있습니다.
데이터 변환 작업(매핑)을 통해 Entity 또는 VO와 데이터를 주고받을 수 있습니다.
일반적으로 데이터를 간결하게 표현하며, Validation 로직을 포함할 수 있습니다.
사용 사례:
컨트롤러 ↔ 서비스 간 객체 교환.
외부 시스템(API) 요청/응답 데이터를 매핑할 때.
직렬화 및 역직렬화(예: JSON 변환) 목적.
VO (Value Object)
정의: 값(데이터)을 표현하기 위해 사용되는 객체. 불변성을 가지며, 두 VO가 같은 값을 가지면 동일하다고 간주됩니다.
특징:
불변성: 생성 후 값이 변경되지 않습니다.
비즈니스 로직 포함 가능: 값과 관련된 도메인 로직이 포함될 수 있습니다.
데이터의 상태를 읽기 전용으로 다룹니다.
사용 사례:
다른 파일이나 외부 시스템(API, 파일, 환경 변수 등)에서 값을 읽어올 때.
값 자체가 도메인 모델에서 중요한 의미를 가질 때.
우리 서비스에서는 보통 데이터 테이블에 직접 붙게 되는 상황에만 entity 를 사용하고 대부분은 dto를 사용합니다.
온디맨드에서 결과를 파일로 전달 받는 경우에는 그 파일을 읽을때 vo 객체를 사용합니다.
entity, dto, vo 간의 변환은 굉장히 빈번하게 일어납니다. 특히 entity는 로직 내에서 그대로 사용되는 경우가 거의 없고 dto 로 변환해서 사용하는게 일반적입니다.
따라서 모든 read 과정에는 entity -> dto 로 변환하는 과정이, write 과정에는 dto -> entity 로 변환하는 과정이 필수적입니다.
우리 서비스에서는 이러한 맵핑 코드를 자동으로 생성하는 mapper 라이브러리를 사용해 자동 맵핑이 이루어지도록 하고 있습니다.
다른 프로젝트 구조
지금까지 설명한 구조는 Spring MVC 패턴에 따라 설계된 아키텍처 입니다.
이 밖에도 DDD, 헥사고날 등 서버의 레이어설계에 대한 방법론은 여러가지가 있으며, 어떤 방식을 차용하냐에 따라 디렉터리 구조는 달라질 수 있습니다.
그래도 기본적으로 비지니스 로직을 구현한 클래스는 service, 디비에 붙을 때는 repository << 이런식의 명명규칙을 사용한다는 점은 비슷하므로, 위 내용을 기준으로 다양한 방법론을 접해보시는 것도 좋을거라 생각합니다.
💡 참고 자료:
링크나 참고한 자료 출처를 여기에 적어 주세요.
The text was updated successfully, but these errors were encountered:
📝 Spring Boot 프로젝트 구조
📚 주제:
스프링 부트의 프로젝트 구조에 대한 설명
🎯 스터디 목표
스프링 부트의 프로젝트 구조를 설명하고, 다 파트의 관점에서 자주 보게될 몇 가지 파일을 설명합니다.
📖 핵심 내용:
프로젝트 구조
<흐름>
entity, dto, vo
Entity
DTO (Data Transfer Object)
VO (Value Object)
우리 서비스에서는 보통 데이터 테이블에 직접 붙게 되는 상황에만 entity 를 사용하고 대부분은 dto를 사용합니다.
온디맨드에서 결과를 파일로 전달 받는 경우에는 그 파일을 읽을때 vo 객체를 사용합니다.
entity, dto, vo 간의 변환은 굉장히 빈번하게 일어납니다. 특히 entity는 로직 내에서 그대로 사용되는 경우가 거의 없고 dto 로 변환해서 사용하는게 일반적입니다.
따라서 모든 read 과정에는 entity -> dto 로 변환하는 과정이, write 과정에는 dto -> entity 로 변환하는 과정이 필수적입니다.
우리 서비스에서는 이러한 맵핑 코드를 자동으로 생성하는 mapper 라이브러리를 사용해 자동 맵핑이 이루어지도록 하고 있습니다.
다른 프로젝트 구조
지금까지 설명한 구조는 Spring MVC 패턴에 따라 설계된 아키텍처 입니다.
이 밖에도 DDD, 헥사고날 등 서버의 레이어설계에 대한 방법론은 여러가지가 있으며, 어떤 방식을 차용하냐에 따라 디렉터리 구조는 달라질 수 있습니다.
그래도 기본적으로 비지니스 로직을 구현한 클래스는 service, 디비에 붙을 때는 repository << 이런식의 명명규칙을 사용한다는 점은 비슷하므로, 위 내용을 기준으로 다양한 방법론을 접해보시는 것도 좋을거라 생각합니다.
💡 참고 자료:
The text was updated successfully, but these errors were encountered: