Layered Architecture Pattern

윤태규·2024년 1월 15일

01. 아키텍처 패턴 (Architecture Pattern)

  • 1) 아키텍처 패턴 (Architecture Pattern) 💡 **아키텍처 패턴은 소프트웨어의 구조를 구성하기위한 가장 기본적인 토대를 제시합니다.** - **아키텍처 패턴**은 각각의 **시스템**들과 그 **역할**이 정의되어 있고, 여러 시스템 사이의 **관계**와 **규칙** 등이 포함되어 있습니다. - 검증된 구조로 개발을 진행하기 때문에 **안정적인 개발**이 가능합니다. - **복잡한 도메인 문제**를 해결할 때, 아키텍처 패턴을 사용하면 **모델**이나 **코드**를 더 쉽게 변경할 수 있다는 측면에서 **큰 이익**을 얻을 수 있습니다.
  • 2) 대표적인 아키텍처 패턴
    • MVC 패턴(Model View Controller Pattern) **MVC 패턴(Model View Controller Pattern)
  출처:** [https://developer.mozilla.org](https://developer.mozilla.org/ko/docs/Glossary/MVC) MVC 패턴(Model View Controller Pattern)
      출처:
      https://developer.mozilla.org
      • 사용자 인터페이스(UI)가 필요한 어플리케이션에서 많이 사용되는 패턴
      • 모델(Model): 데이터와 비즈니스 로직을 담당
      • 뷰(View): 사용자 인터페이스(UI)를 담당
      • 컨트롤러(Controller): 클라이언트의 요청을 모델과 뷰로 전달해주는 역할을 담당
    • 계층형 아키텍처 패턴(Layered Architecture Pattern) 출처: [O’REILLY](https://www.oreilly.com/library/view/software-architecture-patterns/9781491971437/ch01.html) 출처: O’REILLY
      • 시스템의 서로 다른 기능을 여러 계층(Layer)으로 분할하는 패턴
      • 일반적으로 컨트롤러(Controller), 서비스(Service), 저장소(Repository) 계층으로 분리됨
    • 클린 아키텍처 패턴(Clean Architecture) 클린 아키텍처(Clean Architecture)
  출처: [http://blog.cleancoder.com/](http://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html) 클린 아키텍처(Clean Architecture)
      출처: http://blog.cleancoder.com/
      • 소프트웨어를 내부 도메인으로 향하는 의존성을 가지는 여러 계층으로 분리하는 패턴
      • 클라이언트의 요청 처리, 데이터베이스 조작, 외부 시스템과의 통신은 외부 계층에서 처리
      • 소프트웨어의 유지보수성과 확장성을 향상시키는 것이 주요 목표
    • 마이크로 서비스 아키텍처 패턴(Microservices Architecture Pattern) **마이크로 서비스 아키텍처 패턴(Microservices Architecture Pattern)
  출처:** [https://learn.microsoft.com](https://learn.microsoft.com/ko-kr/azure/architecture/guide/architecture-styles/microservices) 마이크로 서비스 아키텍처 패턴(Microservices Architecture Pattern)
      출처:
      https://learn.microsoft.com
      • 시스템을 작고, 독립적으로 배포 가능한 서비스로 분할하는 패턴
      • 하나의 시스템에서 다양한 언어와 프레임워크를 도입할 수 있는 패턴
      • 서비스 간의 통신은 API 또는 이벤트 기반 아키텍처(EDA, Event Driven Architecture)를 통해 통신합니다.
  • 3) 아키텍처 패턴을 도입하기 전에 고민해야 할 것
    1. 아키텍처 패턴이 주는 이점비용에 대한 확실한 이유가 있어야합니다.

    2. 해당하는 아키텍처 패턴을 채택했을 때 어떤 장단점이 존재하는지 명확하게 인지해야 합니다.

    3. 여러 계층을 추가하기 위해 들이는 노력시간을 투자할 만한 가치가 있을 정도로 어플리케이션도메인복잡한 경우에만 아키텍처 패턴을 도입해야 합니다.

      → **가벼운 어플리케이션**에 **복잡한 아키텍처 패턴**을 도입하는건 의미 없는 코스트가 소모될 수 있어요.🥲
      🔥 **아키텍처 패턴**을 도입하기 전 여러분들이 어떠한 **문제를 해결**하고 싶은것인지, 어떤 **장단점이 존재**하는지 확실하게 **인지**한 상태에서 도입하는 것을 추천드립니다. 🙂

02. 계층형 아키텍처 패턴 (Layered Architecture Pattern)

  • 1) 계층형 아키텍처 패턴 (Layered Architecture Pattern) 💡 **계층형 아키텍처 패턴(Layered Architecture Pattern)**은 시스템을 **여러 계층으로 분리하여 관리**하는 아키텍처 패턴입니다. 현재 가장 널리 채택되고 있는 아키텍처 패턴 중 하나입니다. **단순**하고 **대중적**이면서 **비용도 적게** 들어 사실상 모든 어플리케이션의 **표준 아키텍처**입니다. 어떤 아키텍처 패턴을 도입할지 확신이 없을 때에는 **계층형 아키텍처 패턴**은 좋은 선택지가 될 수 있습니다. **계층형 아키텍처 패턴**은 **각 계층을 명확하게 분리해서 유지**하고, **각 계층이 자신의 바로 아래 계층에만 의존**하게 만드는 것이 **목표**입니다. ![출처: [O’REILLY](https://www.oreilly.com/library/view/software-architecture-patterns/9781491971437/ch01.html)](https://s3-us-west-2.amazonaws.com/secure.notion-static.com/43668e97-0e44-4b32-9173-a7c6e261f803/sapr_0101.png) 출처: [O’REILLY](https://www.oreilly.com/library/view/software-architecture-patterns/9781491971437/ch01.html) **계층화**의 핵심은 **각 계층이 높은 응집도(Cohesion)**를 가지면서, 다른 계층과는 **결합도(Coupling)를 최소화** 하는 것입니다. 여기서 **상위 계층**은 **하위 계층**을 **사용할** 수 있지만, **하위 계층**은 자신이 어떤 **상위 계층**에 속하는지 알 필요없이, **독립적으로 동작**할 수 있어야합니다. 예를 들어, **데이터 엑세스 계층 (Data Access Layer)**은 **비즈니스 로직 계층 (Business Logic Layer)**에 어떤 코드들이 있는지 알 수 조차 없고, 사용하면 안된다는 거겠죠? 일반적으로 **계층형 아키텍처 패턴**의 경우 **규모가 작은 어플리케이션의 경우 3개의 계층**, **크고 복잡한 경우는 그 이상의 계층으**로 구성됩니다. 저희가 이번 섹션에서 알아볼 아키텍처 패턴은 **3계층 아키텍처(3-Layered Architecture)**입니다. 📌 **3계층 아키텍처**에서 구성되는 각각의 **계층(Layer)**는 아래와 같습니다. - **프레젠테이션 계층 (Presentation Layer)** - **비즈니스 로직 계층 (Business Logic Layer)** - **데이터 엑세스 계층 (Data Access Layer) | 영속 계층(Persistence Layer)**
  • 2) 계층형 아키텍처 패턴의 장점 👉 저희는 시스템을 계층별로 아키텍처를 분리했을때 아래의 **장점**을 얻을 수 있습니다. - **관심사를 분리**하여 현재 구현하려하는 **코드**를 **명확하게 인지**할 수 있습니다. - 각 계층은 서로 독립적이며, 의존성이 낮아 **모듈**을 **교체**하더라도 **코드 수정이 용이**합니다. - 각 계층별로 **단위 테스트**를 작성할 수 있어 **테스트 코드**를 조금 더 **용이**하게 **구성**할 수 있습니다.
  • 3) 3계층 아키텍처 (3-Layered Architecture) 📒 **3-Layered Architecture**는 주로 아래의 3가지 계층으로 구성됩니다. 1. **컨트롤러(Controller)** : 어플리케이션의 가장 바깥 부분, **요청/응답**을 처리 - 클라이언트의 **요청(Request)**을 수신 한 후 서버에서 처리된 **결과**를 **반환(Response)**해주는 **역할**을 담당합니다. 2. **서비스(Service)** : 어플리케이션의 중간 부분, API의 **핵심적인 동작**이 많이 일어나는 부분 - 아키텍처의 가장 핵심적인 **비즈니스 로직이 수행**되는 부분입니다. 3. **저장소(Repository)** : 어플리케이션의 가장 안쪽 부분, **데이터베이스와 맞닿아 있음.** - 실제 **데이터베이스와 통신**하는 계층입니다. 📌 **3-Layered Architecture**에서는 아래의 **플로우**를 기반으로 로직이 수행됩니다. 1️⃣  **클라이언트(Client)**가 어플리케이션에 **요청(Request)**을 보냅니다. 2️⃣  **요청(Request)**을 URL에 알맞은 **컨트롤러**(**Controller)**가 수신 받습니다. 3️⃣  **컨트롤러**(**Controller)**는 **요청**을 **처리**하기 위해 **서비스(Service)**를 호출합니다. 4️⃣  **서비스(Service)**는 필요한 **데이터**를 가져오기 위해 저**장소(Repository)**에게 **데이터를 요청**합니다. 5️⃣  **서비스(Service)**는 **저장소(Repository)**에서 가져온 데이터를 **가공**하여 **컨트롤러**(**Controller)**에게 **데이터**를 전달합니다. 6️⃣  **컨트롤러**(**Controller)**는 **서비스(Service)**의 **결과물(Response)**을 **클라이언트(Client)**에게 전달해줍니다. 👉 서버 개발자들은 서버에서의 처리과정이 대부분 유사하다는 사실을 깨닫고, **Controller, Service, Repository** 라는 3개의 계층으로 분리하였습니다. 각 계층 별로 하는 일을 정리해 보겠습니다. 1. **컨트롤러(Controller)** !https://s3-us-west-2.amazonaws.com/secure.notion-static.com/9ab055dc-a05c-475b-9ca1-f7b986983024/Untitled.png - 클라이언트의 **요청(Request)**을 받습니다. - 요청에 대한 처리는 **서비스에게 위임**합니다. - 클라이언트에게 **응답(Response)**을 반환합니다. 2. **서비스(Service)** !https://s3-us-west-2.amazonaws.com/secure.notion-static.com/326eac47-e0a1-4871-a29b-4e7d80704a84/Untitled.png - 사용자의 **요구사항을 처리**하는 **실세 중에 실세!!!** - 현업에서는 **서비스 코드**가 계속 확장되는 문제가 발생할 수 있습니다. - DB 정보가 필요할 때는 **Repository**에게 **요청**합니다. 3. **저장소(Repository)** !https://s3-us-west-2.amazonaws.com/secure.notion-static.com/914029fa-aa47-4ddd-96e1-c41e9d090332/Untitled.png - 데이터베이스 관리 (연결, 해제, 자원 관리) 역할을 담당합니다. - 데이터베이스의 **CRUD 작업**을 처리합니다. 👉 그럼 전체적으로 보면 다음과 같이 연결되겠죠? ![3-Layered Architecture](https://s3-us-west-2.amazonaws.com/secure.notion-static.com/25b09b2a-863b-4fa5-9ac0-1eab0f31bdba/Untitled.png) 3-Layered Architecture
  • 4) Express로 구현하는 3계층 아키텍처 👉 저희는 Node.js의 Express.js를 활용하여 **3계층 아키텍처 패턴**을 구현할 예정입니다. **3계층 아키텍처 패턴**을 적용한 Express.js 프로젝트의 **디렉토리 구조(Directory Structure)**를 살펴보고, 이에 맞춰 프로젝트를 설정 해보도록 하겠습니다! 아래에 있는 파일을 다운로드 받아 `layered-architecture-pattern-template.zip` 파일을 압축 해제하여 프로젝트를 생성해주세요! - **[코드스니펫] 계층형 아키텍처 패턴 프로젝트 - 템플릿** ```bash https://hanghae99-node-example.s3.ap-northeast-2.amazonaws.com/re/layered-architecture-pattern-template.zip ``` [layered-architecture-pattern-template.zip](https://s3-us-west-2.amazonaws.com/secure.notion-static.com/d3646240-ae9c-4e4e-b8a9-b5701ae7e4bb/layered-architecture-pattern-template.zip) - **✅  프로젝트를 설치한 후 꼭 해야할 것!** 1. `**.env` 파일에서 DB 속성을 꼭 변경해주세요!** - **⚠️ 꼭, `DATABASE_URL`을 여러분이 대여한 RDS의 속성값으로 수정해주세요!** - 사용할 데이터베이스 명은 `layered_architecture_pattern_db` 랍니다. ```json // .env # MySQL의 데이터베이스 URL입니다. DATABASE_URL="mysql://root:aaaa4321@express-database.clx5rpjtu59t.ap-northeast-2.rds.amazonaws.com:3306/layered_architecture_pattern_db" ``` 2. **yarn** 패키지를 설치하고, **Prisma**로 **DB**및 **테이블** 정보를 동기화해주세요! ```bash # yarn 패키지 설치 yarn # Prisma를 이용하여 DB 및 테이블 생성 npx prisma db push ``` - **📒 [Directory Structure] 계층형 아키텍처 패턴 프로젝트** ``` 내 프로젝트 폴더 이름 ├── package.json ├── prisma │   └── schema.prisma ├── src │   ├── app.js │   ├── controllers │   │   └── posts.controller.js │   ├── middlewares │   │   ├── error-handling.middleware.js │   │   └── log.middleware.js │   ├── repositories │   │   └── posts.repository.js │   ├── routes │   │   ├── index.js │   │   └── posts.router.js │   ├── services │   │   └── posts.service.js │   └── utils │   └── prisma │   └── index.js └── yarn.lock ``` 이 프로젝트의 디렉토리 구조는 기존 프로젝트와는 조금 다릅니다. 새롭게 `controllers`, `services`, `repositories`라는 폴더들이 생성되었는데요. 이 폴더들은 각 계층별 역할을 담당한답니다. 이제부터 새로운 디렉토리 구조에 맞춰 **3계층 아키텍처** 프로젝트를 구성해보도록 하겠습니다! 😊
profile
끝까지 가자

0개의 댓글