Chapter 4. ES6와 프로젝트 파일 구조의 이해(2)

프로젝트 아키텍처

1. Service-Oriented Architecture(Service Layer Pattern)

Controller - Service Layer - Data Access Layer (Repository Layer)

• Controller: 단순히 요청과 응답 역할만 한다(라우팅 역할)
• Service Layer: Controller로 부터 전달된 요청에 대한 로직을 적용하는 계층
• Data Access Layer(Repository Layer): Service계층에서 데이터베이스 접근이 필요한 경우 데이터에 대한 코드가 작성되는 계층

2. MVC 패턴

Controller - Model - View

• Controller: 요청과 응답 역할과 필요한 로직을 수행한다.
• Model: 데이터, 비즈니스 로직 담당
• View: 사용자가 보게 될 화면 담당(HTML 또는 템플릿 파일에 데이터를 삽입하여 컨트롤러에게 넘긴다)

MVC와 SOA의 차이점

3. 그 외 다른 프로젝트 구조

1. Clean Architecture
2. Microservices Architecture
3. RESTful Architecture
4. Service Layer Pattern
5. Event-Driven Architecture

비즈니스 로직

비즈니스 로직은 지켜야 할 도메인 규칙을 코드로 옮긴 부분이다.

규칙이란, 사용자가 무언가를 요청했을 때 허용할지 말지, 어떻게 처리할지를 정하는 조건과 계산이다.

ex)

• 주문은 얼마 이상이어야 한다
• 재고 없으면 주문 불가
• 관리자만 삭제할 수 있다
• 무료배송은 3만원 이상부터

SOA 아키텍처에서 비즈니스 로직은 대부분 Service계층에서 작성된다

DTO

DTO(Data Transfer Object)는 계층 간 또는 외부로 데이터를 전달할 때, 필요한 정보만 안전하게 담는 전용 객체이다.

• DTO를 사용하는 이유

  1. 필요한 데이터만 보내기 위해(DB 모델은 너무 많은 정보가 있기 때문에 다 보낼 필요가 없음)

  2. 보안(민감한 정보 숨기기)

  3. 계층 간 역할 분리 (도메인 모델vs전송 모델)

  4. API 응답 형식 통일

     ex) 유저 정보 응답

     User 모델 (전체 정보)

     // models/User.js
     const User = {
       id: 1,
       name: "홍길동",
       password: "secret123",
       email: "gildong@example.com",
       role: "admin",
       createdAt: "...",
       updatedAt: "..."
     };

     프론트에 필요한 정보만 주기 위해 DTO 객체를 사용한 예시

     // dtos/UserDTO.js
     class UserDTO {
       constructor(user) {
         this.id = user.id;
         this.name = user.name;
         this.email = user.email;
       }
     }
     
     module.exports = UserDTO;