3 Layer Architecture

왜 3 Layer Architecture를 공부하는가?

First 프로젝트나 코드를 짜면서 대부분의 로직들이 Controller에 쏠리는 경향이 많다. 그러다 보니 코드가 너무나 복잡해지고, 길어지는 현상이 발생했다. 그래서 Final 프로젝트에서는 Controller의 부담을 줄이고자, DB에 접근하는 코드들을 따로 DB폴더를 만들어 짜보았다. 그러니 조금 더 코드가 간결하게 짤 수 있었다.

친형과 프로젝트 로직에 대해서 이야기를 하다가, 비즈니스 로직이라는 것을 듣게 되었다. 그래서 비즈니스 로직이 무엇인가에 대해 알아보게 되었다.

3 Layer Architecture 이란?

3 Layer Architecture은 3 Layer에서 알 수 있듯이, 3개의 층으로 이루어 졌단 뜻이다.

Controller, Service Layer, Data Access Layer 라는 세 개의 층으로 이루어져 있다.

Controller는 client와의 통신에서 필요한 request, response를 다루는 부분이고, Service Layer는 비즈니스 로직을, Data Access Layer은 DB와의 직접적인 통신을 다룬다.

이때 비즈니스 로직은 client와 Data Access Layer 사이에서 데이터를 조종하는 작업이다.

이 구조의 가장 큰 장점은 확장성이다. 레이어 별로 분리하면 언제든지 필요에 따라 각각 독립적으로 크기를 조정하거나 수정할 수 있다.

Controller

1. Controller는 들어오는 client의 요청을 받고 Service에 전달한다.
2. Service에서 작업을 마친 데이터를 받아 client에게 응답한다.

• 주의할 점 Contoller에는 데이터를 가공하는 등의 비즈니스 로직을 추가하면 안된다!

Service

Service Layer는 나머지 애플리케이션에서 모든 비즈니스 로직을 캡슐화 하고 추상화 한다.

• 비즈니스 로직 포함
• Data Access Layer를 활용하여 데이터 베이스와 상호 작용

• controller 계층에 전달할 데이터 리턴

• 주의할 점
  • req, res 활용 하면 안된다.
  • client에 대한 응답 처리를 하면 안된다.
  • 데이터베이스와 직접 상호 작용을 하면 안된다.

Data Access Layer

• Data Access 계층은 쿼리를 수행하여 데이터 베이스와 상호 작용 한다.

나의 로직과의 비교

나의 로직에서는 Controller와 DB의 접근 하는 메소드 들을 DB 폴더가 있었다. Controller에서는 client에서 받는 req, res를 수행을 하고 받은 데이터를 DB 폴더의 메소드와 상호 작용 하여 데이터를 처리를 하고 있었다.

결국 이 로직도 내 생각에는 controller의 부담을 덜으려고 했지만, 그러지 못했다. DB와의 직접적인 상호 작용을 하진 않았지만, Controller와 Service를 합쳐놓는 듯한 느낌이 들었다.

Service 계층을 추가를 하면 조금 더 깔끔하고, 코드의 유지보수와 확장성을 넓힐 수 있다고 생각이 들었다.