[Node] Layered Pattern

1. Layered Pattern 이란?

코드의 구조를 구상할 때 고려할 점은 여러가지입니다. 코드 구조의 하나하나 모두 중요해 매번 좋은 코드의 구조를 생각해 내기는 쉽지 않습니다. 다행히 "코드의 구조를 어떻게 구성하고 관리해야 하는가"에 대한 문제는 이미 많은 개발자들이 다루던 문제며, 이에 관해 정석같은 패턴이 굉장히 많이 나와 있습니다. 레이어드(layered)패턴은 백엔드 API 코드에 가장 널리 적용되는 패턴 가운데 하나입니다.

Multi-tier 아키텍처 패턴이라고도 하는 이 Layered 아키텍처는 코드를 논리적인 부분 혹은 역할에 따라 독립된 모듈로 나누어 구성하는 패턴입니다. 각 모듈이 서로의 의존도에 따라 층층이 쌓듯이 연결되어 전체의 시스템을 구현하는 구조입니다. 그래서 마치 레이어(Layer)를 쌓아 놓은 것 같은 형태의 구조가 됩니다.

즉, 역할에 따라 분리했던 파일들을 사실은 하나의 레이어라 볼 수 있습니다.

각 시스템마다 경우가 다를 수 있으나 일반적으로 보통 다음과 같은 3개의 레어가 존재합니다.

Presentation Layer
Business Layer
Persistence Layer

1️⃣ Presentation Layer

Presentation Layer는 해당 시스템을 사용하는 사용자 혹은 클라이언트 시스템과 직접적으로 연결되는 부분입니다.

백엔드 API에서 엔드포인트(end-point)를 정의하고 전송된 HTTP 요청(request)들을 읽어 들이는 로직을 구현합니다. 하지만 그 이상의 역할은 담당하지 않으며 실제 시스템이 구현하는 비즈니스 로직은 다음 레이어(Layer)로 넘기게 됩니다.

2️⃣ Business Layer

Business Layer는 이름 그대로 비즈니스 로직을 구현하는 부분으로 실제 시스템이 구현해야 하는 로직들을 이 레이어에서 구현하게 됩니다. 예를 들어, API 회원가입 로직 구현 시 회원가입 엔드포인트에서 만일 비밀번호가 8자 넘는지 확인해 8자 미만이면 회원가입을 거부하는 로직 등이 비즈니스 로직입니다. 즉, 우리 회사의 비즈니스를 운영하기 위해 필요한 로직으로 Business Layer에서 구현하게 됩니다.

3️⃣ Persistence Layer

Persistence Layer는 데이터베이스와 관련된 로직을 구현하는 부분입니다. Business Layer에서 필요한 데이터 생성, 수정, 읽기 등을 처리하여 실제 데이터 베이스에 데이터를 저장, 수정, 읽는 역할을 수행합니다.

2. Layered 아키텍처의 핵심 요소

1️⃣ 단방향 의존성

Layered 아키텍처의 핵심 요소는 바로 단방향 의존성과 관심사 분리(Seperation Of Concern)입니다.

단방향 의존성이란, 각각의 레이어는 오직 자기보다 하위에 있는 레이어에만 의존하고 있음을 의미합니다.

Presentation Layer는 Business Layer에게 의존하고, Business Layer는 Persistence Layer에게만 의존하게 됩니다. Presentation Layer에서 Business Layer를 건너뛰고 Persistence Layer에 접근하는 일은 절대 일어나지 않습니다.
Business Layer는 Presentaiton Layer에 대해 완전히 독립적이며, Persistence Layer는 Business Layer나 Presentation Layer에 대해 완전히 독립적입니다.

2️⃣ 관심사 분리(SOC)

관심사 분리란, 각 레이어 별 역할이 구분되어 명확하다는 사실을 의미합니다. 즉, 역할의 중첩이 없습니다.

Presentation layer에는 비즈니스 로직이 전혀 구현되어 있지 않습니다.
Business layer에는 데이터베이스 관련 로직이 전혀 구현되어 있지 않아 데이터 베이스 처리를 하기 위해서 persistence layer의 코드를 호출해서 사용해야 합니다.
음료 제조자가 어떤 과정을 거쳐 제조를 했는지 중간 직원은 알 수 없습니다. 과정을 거친 결과물인 음료만 전달하기 때문입니다. 위의 내용은 이런 맥락과 동일합니다.

3️⃣ Layered 아키텍처 적용 시 장점

Layered로 이루어진 아키텍쳐를 코드에 적용하면 아래와 같은 장점을 누릴 수 있습니다.

확장성: 각 레이어가 서로 독립적이고 역할이 분명하여 서로에게 끼치는 영향을 최소화해 확장하거나 수정
가독성: 레이어가 완벽히 분리되어 있고 역할이 명확해 가독성이 높아짐. 코드의 구조를 파악하기 쉬우며, 각 레이어의 코드 목적이 명확하고 범위도 확실.
재사용성: 레이어가 독립적이므로 business layer는 여러 다른 presentation layer에 적용될 수 있음. Express기반 API 엔드포인트에 적용된 business layer가 다른 프레임워크를 사용한 엔드포인트에 사용될 수도 있음.
테스트 가능성: 이미 명확한 역할에 의해 나뉘어져 있어 각 레이어를 테스트하는 코드도 레이어가 나뉘는 것처럼 명확하게 나눌 수 있음. 복잡한 로직이 아닌 명확하고 범위가 확실한 기능만을 테스트하기 쉬움. 또한 레이어들 자체가 다른 레이어에 사용하는 구조이므로 테스트에 호출해서 테스트 해보기가 쉬움.

3. Layered 아키텍처 적용하기

1️⃣ 역할에 따른 폴더 및 파일 생성

인스타그램의 회원가입 기능에 layered architecutre를 접목해보겠습니다.

현재 app.js 파일에 속해 있는 signUp 함수가 기능을 역할에 따라 나누어 서로 다른 모듈에서 진행하도록 분리합니다. 각 레이어에 속하는 모듈의 이름을 아래와 같이 칭하겠습니다.

Presentation layer -> userController.js
Business layer -> userService.js
Persistence layer -> userDao.js(Data Access Objective)

그러므로 app.js 단일 파일로만 존재하던 구조를 아래 형태로 분리해줍니다.

testServer
├── node_modules
├── package.json
├── routes
|   ├── index.js
│   └── userRoute.js
├── services
│   └── userService.js
├── controllers
│   └── userController.js
├── models
│   └── userDao.js
└── app.js

2️⃣ 역할에 따른 코드 분리

app.js에 작성 될 수 있는 signUp() 함수를 역할에 따라 각각 controller, service, model 모듈로 분리해줍니다.

먼저 기존 코드를 살펴보겠습니다.

// app.js

const express = require('express');

const cors = require('cors');
const morgan = require('morgan');
const dotenv = require("dotenv")
dotenv.config()

const { DataSource } = require('typeorm');

const myDataSource = new DataSource({
	  type: process.env.TYPEORM_CONNECTION,
      host: process.env.TYPEORM_HOST,
      port: process.env.TYPEORM_PORT,
      username: process.env.TYPEORM_USERNAME,
      password: process.env.TYPEORM_PASSWORD,
      database: process.env.TYPEORM_DATABASE
})

myDataSource.initialize()
    .then(() => {
        console.log("Data Source has been initialized!")
    })

const PORT = 3000;
const app = express();

app.use(cors());
app.use(morgan('combined'));
app.use(express.json());

// health check
app.get("/ping", (req, res) => {
  res.status(200).json({"message" : "pong"});
})

// user signup logic
app.post("/users/signup", async (req, res) => {
	const { name, email, profile_image, password } = req.body
    
	await myDataSource.query(
		`INSERT INTO users(
			name,
			email,
			profile_image,
			password
		) VALUES (?, ?, ?, ?);
		`,
		[ name, email, profile_image, password ]
	); 
   res.status(201).json({ message : "successfully created" });
});

이제는 app.js의 내용들을 역할에 따라 코드를 분리해보도록 하겠습니다. 먼저 위의 코드 중 app.js 파일에 계속 유지할 코드는 아래와 같습니다.

1) App: 앱의 초기화

// app.js

const http = require("http");
const express = require('express');
const cors = require('cors');
const morgan = require('morgan');

const dotenv = require("dotenv")
dotenv.config()

const routes = require("./routes");

const app = express();

app.use(cors());
app.use(morgan('combined'));
app.use(express.json());
app.use(routes);

app.get("/ping", (req, res) => {
  res.json({ message: "pong" });
});

const server = http.createServer(app);
const PORT = process.env.PORT;

const start = async () => {
  try {
    server.listen(PORT, () => console.log(`Server is listening on ${PORT}`));
  } catch (err) {
    console.error(err);
  }
};

start();

2) Routes: endpoint 경로 라우팅

외부에서 들어오는 요청을 가장 먼저 맞이하여 하위 폴더로 안내하는 길잡이 역할을 하는 Router 파일입니다.

index.js는 향후 확장성을 고려하여 생성될 수 있는 다양한 Router들을 한 곳에 모아 관리하는 역할을 합니다.

//routes/index.js

const express = require("express");
const router = express.Router();

const userRouter = require("./userRouter");
router.use("/users", userRouter.router);

module.exports = router;

//routes/userRouter.js

const express = require('express');
const userController = require('../controllers/userController');

const router = express.Router();

router.post('/signup', userController.signUp);

module.exports = {
	router
}

3) Controller( Presentation Layer)

다음 API의 엔드포인트들을 정의하고 전송된 HTTP 요청(request)들을 읽어 들이는 로직을 구현하는 Controller입니다.

Controller에는 비즈니스 로직으로 흘러 들어가야할 데이터들이 올바른 형태를 띄고 있는지 선검증 작업이 이루어 집니다.

아래 다양한 예시 중, 서버에서 원하는 특정 데이터의 'Key' 값을 요청 시 전해지지 않았을 때 발생하는 Key Error를 사전에 에러처리로 검열하는 예시입니다.

//controller/userController.js

const userService = require('../services/userService');

const signUp = async (req, res) => {
  try {
    const { name, email, password, profileImage } = req.body;

    if ( !name || !email || !password || !profileImage ) {
      return res.status(400).json({ message: 'KEY_ERROR' });
    }

    await userService.signUp( name, email, password, profileImage );
    return res.status(201).json({
      message: 'SIGNUP_SUCCESS',
    });
  } catch (err) {
    console.log(err);
    return res.status(err.statusCode || 500).json({ message: err.message });
  }
};

module.exports = {
	signUp
}

4) Service

다음은 실제 비즈니스 규칙(Rule)과 로직(Logic)들이 접목되는 Service 레이어의 코드입니다.

어플리케이션을 직접 다루는 운영자 입장에서 기획한 비즈니스 모델들이 접목 되어야 합니다. 아래는 비밀번호의 조합이 특정형태를 띄어야 하는 규칙을 위해 정규 표현식을 도입한 예시입니다.

//service/userService.js

const userDao = require('../models/userDao')

const signUp = async (name, email, password, profileImage) => {
    // password validation using REGEX
    const pwValidation = new RegExp(
      '^(?=.*[A-Za-z])(?=.*[0-9])(?=.*[!@#$%^&*])(?=.{8,20})'
    );
    if (!pwValidation.test(password)) {
      const err = new Error('PASSWORD_IS_NOT_VALID');
      err.statusCode = 409;
      throw err;
    }
      const createUser = await userDao.createUser(
          name,
          email,
          password,
          profileImage
        );
      
        return createUser;
      };
  
  module.exports = {
      signUp
  }

5) Models

다음은 실질적으로 데이터베이스와 소통하는 Model 레이어 입니다. 아래는 typeorm을 이용해 DB에 연결한 후, 앞선 레이어들을 모두 무사히 통과한 데이터들을 DB에 직접 Insert 하는 예시입니다.

//models/userDao.js

const { DataSource } = require('typeorm');

const myDataSource = new DataSource({
	type: process.env.TYPEORM_CONNECTION,
    host: process.env.TYPEORM_HOST,
    port: process.env.TYPEORM_PORT,
    username: process.env.TYPEORM_USERNAME,
    password: process.env.TYPEORM_PASSWORD,
    database: process.env.TYPEORM_DATABASE
})

myDataSource.initialize()
  .then(() => {
    console.log("Data Source has been initialized!");
  })
  .catch((err) => {
    console.error("Error occurred during Data Source initialization", err);
	  myDataSource.destroy();
  });

const createUser = async ( name, email, password, profileImage ) => {
	try {
		return await myDataSource.query(
		`INSERT INTO users(
			name,
			email,
			password
			profile_image,
		) VALUES (?, ?, ?, ?);
		`,
		[ name, email, password, profileImage ]
	  );
	} catch (err) {
		const error = new Error('INVALID_DATA_INPUT');
		error.statusCode = 500;
		throw error;
	}
};

module.exports = {
  createUser
}

3️⃣ Layer dependency(의존성) 순서

App → Router → Controller → Service → Models 순으로 갈수록 데이터베이스의 접근에 가까워집니다.

각각의 파일에 Export한 module들을 어느 파일들이 require 하고 있는지 그 연결흐름을 잘 살펴보면, 상위 레이어에서 오직 하위 레이어로만 의존하는 방향성의 특성이 드러납니다.

다음은 실제 Express를 이용한 서버 웹 개발 시 Layered Pattern을 이루는 기본 구조입니다.

app.js | server.js : Express App으로 서버를 여는 로직으로 Express APP 인스턴스를 만들고, 필요한 미들웨어를 붙이는 로직입니다. 경우에 따라 app.js 와 server.js에 각기 다른 기능을 유도하여 두 가지 파일 모두 유지할 수도 있고, 둘의 기능을 한 데 모아 한 파일만을 유지할 수도 있습니다. 개발자의 의도에 맞게 파생되어질 수 있는 다양한 경우의 수에 유의하며 코드를 작성해야 합니다.
Routes: 라우팅(엔드 포인트 나누기) 로직을 담당합니다.
Controllers: 엔드포인트에 해당하는 함수 로직 - http 요청에 따른 에러 핸들링, service 로직에서 데이터를 받아와 응답으로 내보내는 로직입니다.
Services: controller에서 넘겨받은 인자로 다양한 알고리즘(필터, 정렬 등)을 처리해 데이터에 접근하는 로직입니다.
models: 데이터베이스에 접근하기 위한 모델(DAO)이 정의되어 있는 폴더입니다.

아래 모듈은 의존성 없이 다양한 레이어에 사용될 수 있지만 반복되는 로직이기에 분리해 놓은 폴더입니다.

middlewares: 컨트롤러에 닿기 전 반복되는 로직을 모듈화 해 놓은 폴더입니다. (ex. vaildateToken - 인증/인가)
utils: 의존성 없이 모든 레이어에 공통적으로 자주 사용되는 로직을 모듈화 해 놓은 폴더입니다. (ex. errorGenerator)
.env: 프로젝트 내 사용할 환경 변수를 선언해 놓는 곳이며 샘플 양식은 .env.sample에 따로 기입해 공유합니다.
node_modules: 노드 패키지 모듈입니다.
.gitignore: 위의 두 모듈을 깃이 관리하지 않도록 합니다.
package.json: 노드 모듈을 관리하는 파일입니다.

저작자표시 비영리

'BackEnd' 카테고리의 다른 글

[API] RESTful API란? (0)	2023.11.15
Git Rebase란? Git Merge와 Git Rebase의 차이점 (0)	2023.11.14
API Architecture에 대해 (0)	2023.11.12
[Node] Express를 이용해 API 서버 만드는 법 2(Connect DB) (0)	2023.11.04
[Node] Express를 이용해 API 서버 만드는 방법 1 (0)	2023.11.03

시작

[Node] Layered Pattern

1. Layered Pattern 이란?

2. Layered 아키텍처의 핵심 요소

3. Layered 아키텍처 적용하기

'BackEnd' 카테고리의 다른 글

댓글

티스토리툴바

[Node] Layered Pattern

1. Layered Pattern 이란?

2. Layered 아키텍처의 핵심 요소

3. Layered 아키텍처 적용하기

'BackEnd' 카테고리의 다른 글

관련글

댓글

티스토리툴바