[ TIL ] Day 48 & 49 - 디자인 패턴 / 코드 레벨 아키텍쳐

🗓️ 수업 일자 : 2025.12.2~3

✨ 오늘의 수업 평가 :  [ GOOD ]  머리가 터질 뻔했지만 배웠다 💥🤯📚

 

이론이라고 무시했다간 큰코다칠 개념들 ㅋㅋㅋ

어제 오후부터 지금까지 거의 하루를 통째로 개념 이해에 힘썻다 

강사님이 1차로 알려주시고, 2차로 유튜브에서 개념 검색 해 보고, 3차로 GPT / Gemini와 토론하며 겨우 이해했다

이해는 했는데.. 현실에서 어떻게 사용할 지는 아직 잘 모르겠다 ㅋㅋㅋㅋㅋㅋ 

그래도 이해 했다는 것에 의미를 두며 😉👍  

 

👩‍💻 [개인 프로젝트] 오늘 작업 내용 💻
- 스프린트 미션 5 : 기본 셋팅..해야하는데 브랜치 꼬여서.. 해결..ㅋㅋ

 

📝  오늘 배운 내용  

- 디자인 패턴 

- 코드레벨 아키텍쳐

 

---

1. 디자인 패턴 

디자인 패턴이란?

개발 작업 중 계속 반복되는 문제들에 대해, 이미 검증된 구조를 사용하여 깔끔하고 유지보수 잘 되게 해결하는 공식 레시피

클래스, 함수, 인스턴스, 객체간의 관계를 패턴화 한 것으로, 코드 동작 방식에 대한 구조화

 

 

디자인 패턴 종류

1) Singleton

• 클래스를 내부에서만 생성하는 구조로 제작하여, 단 하나의 인스턴스로 공유하는 패턴.
• 해당 클래스를 선언하여 만들어진 객체들은 모두 같은 주소를 가짐.
• 이미 클래스 안에서 선언해서 사용하기 때문에, 외부에서 무분별하게 객체를 생성 하는 것을 막을 수 있는 방식
• 메모리와 자원 낭비를 막을 수 있고, 전역적으로 동일한 값을 유지해야 할 때 사용 
• 주요 사용처 : 로그(중복 기록 막음), DB 커넥션(단일 연결로 비용 절약), 환경변수(모든 작업에서 동일하게 사용) 등

Singleton 패턴 설명

 

 

 

2) Factory

• 단어 그대로 공장처럼 특정 클래스/함수를 통과하여 동일한 결과를 계속 만들어 내는 패턴 
• 종류만 여러 개 이고, 비슷한 결과물을 출력 해 낼 때 주로 사용
• 일종의 자바스크립트 메서드처럼, 사용자는 내부의 구조를 구체적으로 알지 못해도 호출만 제대로 하면 알맞은 결과물이 생성 = 직접 new 하지 않고, 어떤 객체를 만들지 선택/생성 책임을 팩토리에게 맡기는 패턴

Facrory 패턴 설명

 

 

 

3) Decorator 

• 초기 만들었던 "원본 기능"은 그대로 두고, 추가 로직을 옵션처럼 동적으로 추가 하는 패턴
• 일종의 미들웨어 구조처럼, 옵션을 조합하면 무한 확장이 가능 해 짐
• 상속보다 유연하고, 원본 유지가 쉬움 
  : 클래스 상속은 기존의 클래스를 확장해서 새롭게 선언 해 나가는 구조이지만, 
    데코레이션은 기존 클래스를 유지하며 기능(함수)를 추가하는 구조이기 때문에 기존을 유지하며 발전이 가능함

Decorator 패턴 설명

 

 

 

4) Observer

• Subscriber, Listener 패턴이라고도 불림
• 해당 패턴에는 역할에 따라 크게 2가지로 나뉨 
  • Subject : 상태를 가지고 있으며, 상태가 변하는 경우 자신에게 소속 된 Observer에게 notify() 등 특정 기능을 활용하여 변경된 내용을 고지하는 역할
  • Observer : Subject로 부터 상태 변경 알림을 받으면, 그에 맞는 특정 작업을 시행하는 역할
• 상태 변화 관리가 필요하거나, 하나의 변화가 여러 객체에 영향을 주는 서비스를 만들때 사용하는 패턴

Observer 패턴 설명 (아이들..지각..미안..)

 

 

 

2. 코드레벨 아키텍쳐

코드레벨 아키텍처란? 

프로젝트 전체 구조를 다루는 규칙으로, 폴더 구조 / 레이어 분리 / 모듈 구성 / 파일 역할 등 프로젝트의 전체 뼈대를 설계하는 것

 

1) MVC : Model - View - Controller 형태로 책임을 분리해서 개발하는 구조

• Model(모델) : 데이터베이스와 상호작용, 비지니스 로직 관리
• View(뷰) : 레이아웃, 화면 처리. 사용자 인터페이스를 담당
• Controller(컨트롤러) : 사용자 요청을 처리하기 위해 모델과 뷰 사이에서 명령을 전달하는 역할

📦 src/
 ├── controllers/             // 1. Controller (흐름 제어 및 중개자)
 │    ├── user.controller.ts  // 요청을 받아 Service(Model 로직)에 전달
 │    └── board.controller.ts
 ├── models/                  // 2. Model (데이터 및 비즈니스 로직)
 │    ├── user.model.ts       // DB Entity, ORM 모델 정의 및 데이터 처리 로직
 │    └── board.model.ts
 ├── views/                   // 3. View (사용자 인터페이스)
 │    ├── users/
 │    │    └── profile.ejs    // EJS, Pug 등 템플릿 파일
 │    └── boards/
 │         └── list.ejs
 ├── dtos/                    // DTO (Controller와 Model 간 데이터 전송 객체)
 │    ├── user.dto.ts
 │    └── board.dto.ts
 └── routes/                  // URL과 Controller 연결 (Express Router)
      ├── user.router.ts
      └── index.ts

 

 

 

2) Layered Architecture : 작업을 여러 계층으로 나눠서 책임을 분리하는 설계 

• 표현 계층 Presentation Layer : 인터페이스 제공, HTTP 관련 처리 (리퀘스트/리스폰스)만 전담하는 계층
• 비지니스 계층 Service Layer : 실제 비지니스 로직을 처리하는 계층
• 영속성 계층 Data Access Layer : 데이터베이스와 관련된 작업을 처리 해 주는 계층
• 데이터베이스 계층 Database Layer : 실제 데이터가 저장되고, 관리를 진행하는 물리적인 영역. DBMS를 의미.
• DTO (Data Transfer Object) :  데이터 전송만을 목적으로 하는 객체로, 어떠한 비지니스 로직도 포함하지 않음

📦 src/
 ├── controllers/             // 1. 표현 계층 (Presentation) - HTTP 요청/응답 처리
 │    ├── user.controller.ts
 │    └── board.controller.ts
 ├── services/                // 2. 비즈니스 계층 (Application/Business) - 핵심 로직
 │    ├── user.service.ts
 │    └── board.service.ts
 ├── repositories/            // 3. 영속성 계층 (Persistence/Data Access) - DB 통신
 │    ├── user.repository.ts
 │    └── board.repository.ts
 ├── models/                  // 데이터 모델 정의 (DB 테이블 구조와 1:1 매핑) = Prisma 적용!
 │    ├── User.ts             // TypeORM/Mongoose 등 ORM의 Entity/Schema 파일
 │    └── Board.ts
 ├── dtos/                    // DTO (Data Transfer Object) - 계층 간 데이터 전달 규격
 │    ├── user.dto.ts         // UserRequest, UserResponse 등의 타입 정의
 │    └── board.dto.ts
 └── common/                  // 공통 유틸리티, 미들웨어, 에러 처리 등
 
 // +@ 추가 파일
 ├── routes/                  // 라우팅 설정 파일 (URL과 Controller 매핑)
 │    └── index.ts
 ├── app.ts                   // Express 앱 설정 및 미들웨어 등록
 └── server.ts                // 서버 시작 파일

 

 

3) Monolithic Architecture : 하나의 단일 레포를 기반으로 서비스를 구현, 하나의 서버에서 모든 서비스를 제공

📦 src/
 ├── user/                    // 1. 사용자(User) 도메인 - 하나의 기능 단위
 │    ├── user.controller.ts  // 표현 계층: HTTP 요청 처리
 │    ├── user.service.ts     // 비즈니스 계층: 핵심 로직
 │    ├── user.repository.ts  // 영속성 계층: DB 접근
 │    ├── user.model.ts       // DB Entity/Model 정의
 │    └── user.dto.ts         // 해당 기능 전용 DTO
 │
 ├── board/                   // 2. 게시판(Board) 도메인 - 또 다른 기능 단위
 │    ├── board.controller.ts
 │    └── ... (Service, Repository 등 동일)
 │
 ├── payment/                 // 3. 결제(Payment) 도메인 - 또 다른 기능 단위
 │    ├── payment.controller.ts
 │    └── ... (Service, Repository 등 동일)
 │
 ├── common/                  // 공통 기능 및 설정
 │    ├── middleware/         // 인증/로깅 등 공통 미들웨어
 │    ├── utils/              // 공통 유틸리티 함수
 │    └── config/             // DB, 환경 설정
 └── app.ts                   // Express 앱 설정, 미들웨어 통합

 

 

4) Microservices Architecture : 작고 독립적인 여러 서비스로 분리하여 설계. 하나의 서버는 하나의 서비스만 담당

              [API Gateway]
                    │
     ┌──────────────┼──────────────┐
     │              │              │
 [User Service]  [Product Service]  [Order Service]
     │              │              │
 독립 DB         독립 DB         독립 DB
     │              │              │
     └────── 메시지큐(옵션) ────────┘

하나의 폴더 안에서 서비스가 만들어 지는 구조가 아니라 
여러 서비스들이 모여 하나의 큰 서비스를 제공하는 구조

 

 

---

 

📃 내일은 뭘 배울까 🤔

- 타입스크립트 실무 적용