5.2 객체 지향 설계 5 원칙 (SOLID)
01. 객체 지향 설계 5원칙 (SOLID)
- 객체 지향 설계 5원칙
객체 지향 프로그래밍 및 설계의 다섯 가지 핵심 원칙을 SOLID라고 부른다. - 단일 책임의 원칙 (Single Responsibility Princple, SRP)
하나의 객체는 단 하나의 책임을 가져야 한다.
즉, 클래스나 모듈을 변경할 이유가 단 하나 뿐이어야 한다는 원칙. - 개방-폐쇄 원칙 (Open-Closed Principle, OCP)
소프트웨어 엔티티 또는 개체(클래스, 모듈, 함수 등)는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다.
- 즉, 소프트웨어 개체의 행위는 확장될 수 있어야 하지만, 개체를 변경해서는 안 된다.
- 조금 더 쉽게 설명하자면, 기존 코드에 영향을 주지 않고 소프트웨어에 새로운 기능이나 구성 요소를 추가할 수 있어야 한다는 것이다. - 리스코프 치환 원칙 (Liskov substitution principle, LSP)
어플리케이션에서 객체는 프로그램의 동작에 영향을 주지 않으면서, 하위 타입의 객체로 바꿀 수 있어야 한다.
- 즉, S가 T의 하위 유형이라면, 프로그램의 기능에 변화를 주지 않고서도 T 타입의 객체를 S 객체로 대체할 수 있어야 한다. - 인터페이스 분리 원칙 (Interface segregation principle, ISP)
특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다.
- 클라이언트는 필요로 하지 않는 기능을 가진 인터페이스에 의존해서는 안 되고, 최대한 인터페이스를 작게 유지해야 한다.
- 즉, 사용자가 필요하지 않은 것들에 의존하지 않도록, 인터페이스는 작고 구체적으로 유지해야 한다. - 의존성 역전 원칙 (Dependency Inversion Princple, DIP)
프로그래머는 추상화에 의존해야지, 구체화에 의존하면 안 된다.
- 즉, 높은 계층의 모듈(도메인)이 저수준의 모듈(하부구조)에 직접 의존해서는 안 된다.
5.3 Layered Architecture Pattern
01. 아키텍처 패턴 (Architecture Pattern)
- 아키텍처 패턴 (Architecture Pattern)
아키텍쳐 패턴은 소프트웨어의 구조를 구성하기 위한 가장 기본적인 토대를 제시한다. - 대표적인 아키텍쳐 패턴
- MVC 패턴(Model View Controller Pattern)
- 계층형 아키텍처 패턴(Layered Architecture Pattern)
- 클린 아키텍처 패턴(Clean Architecture Pattern)
- 마이크로 서비스 아키텍쳐 패턴(Microservices Architecture Pattern) - 아키텍쳐 패턴을 도입하기 전에 고민해야 할 것
아키텍쳐 패턴을 도입하기 전 여러분들이 어떠한 문제를 해결하고 싶은 것인지, 어떤 장단점이 존재하는지 확실하게 인지한 상태에서 도입하는 것을 추천드립니다.
02. 계층평 아키텍처 패턴 (Layered Architecture Pattern)
- 계층형 아키텍처 패턴 (Layered Architecture Pattern)
계층형 아키텍처 패턴은 시스템을 여러 계층으로 분리하여 관리하는 아키텍처 패턴입니다. 현재 가장 널리 채택되고 있는 아키텍처 패턴 중 하나입니다.
3계층 아키텍처의 각각의 계층
- 프레젠테이션 계층 (Presentation Layer)
- 비즈니스 로직 계층 (Business Logic Layer)
- 데이터 엑세스 계층 (Data Access Layer) | 영속 계층 (Persistence Layer) - 계층형 아키텍처 패턴의 장점
- 관심사를 분리하여 현재 구현하려는 코드를 명확하게 인지할 수 있다.
- 각 계층은 서로 독립적이며, 의존성이 낮아 모듈을 교체하더라도 코드 수정이 용이하다.
- 각 계층별로 단위 테스트를 작성할 수 있어 테스트 코드를 조금 더 용이하게 구성할 수 있다. - 3계층 아키텍처 (3-Layered Architecture)
1. 컨트롤러(Controller)
: 어플리케이션의 가장 바깥 부분, 요청/응답을 처리
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)에게 전달해준다. - Express로 구현하는 3계층 아키텍처
5.4 Layered Architecture Pattern - Controller
01. 컨트롤러 (Controller)
- 프레젠테이션 계층(Presentation Layer)이란?
프레젠테이션 계층(Presentation Layer)은 3계층 아키텍처 패턴에서 가장 먼저 클라이언트의 요청(Request)을 만나게 되는 계층이며, 대표적으로 컨트롤러(Controller)가 이 역할을 담당한다. - 컨트롤러(Controller)란?
컨트롤러(Controller)란 클라이언트의 요청(Request)을 처리하고, 서버에서 처리된 결과를 반환(Response)하는 역할을 담당한다. - Express로 구현하는 컨트롤러
5.5 Layered Architecture Pattern - Service
01. 서비스 (Service)
- 서비스 계층(Service Layer)이란?
서비스 계층(Service Layer), 다른 이름으로는 비즈니스 로직 계층(Business logic layer)은 아키텍처의 가장 핵심적인 비즈니스 로직을 수행하고 클라이언트가 원하는 요구사항을 구현하는 계층입니다. - 서비스 계층의 장단점
서비스 계층의 장점
- 사용자의 유즈 케이스(Use Case)와 워크플로우(Workflow)를 명확히 정의하고 이해할 수 있도록 도와준다.
- 비즈니스 로직이 API 뒤에 숨겨져 있으므로, 서비스 계층의 코드를 자유롭게 수정하거나 리팩터링할 수 있다.
- 저장소 패턴(Repository Pattern) 및 가짜 저장소(Fake Repository)와 조합하면 높은 수준의 테스트를 작성할 수 있다.
서비스 계층의 단점
- 서비스 계층 또한 다른 추상화 계층이므로, 잘못 사용하면 코드의 복잡성을 증가시킬 수 있다.
- 한 서비스 계층이 다른 서비스 계층에 의존하는 경우, 의존성 관리가 복잡해질 수 있다.
- 서비스 계층에 너무 많은 기능을 넣으면 빈약한 도메인 모델(Anemic Domain Model)과 같은 안티 패턴이 생길 수 있다. - Express로 구현하는 서비스 계층
5.6 Layered Architecture Pattern - Repository
01. 저장소 (Repository)
- 저장소 계층(Repository Layer)이란?
저장소 계층(Repository Layer)은 데이터 엑세스 계층(Data Access Layer)이라고도 불리는데, 주로 데이터베이스와 관련된 작업을 처리하는 계층이다. - 저장소 계층의 장단점
저장소 계층의 장점
- 데이터 모델과 데이터 처리 인프라에 대한 사항을 분리했기 때문에, 단위 테스트(Unit test)를 위한 가짜 저장소(Mock Repository)를 쉽게 만들 수 있다.
- 도메인 모델을 미리 작성하여, 처리해야 할 비즈니스 문제에 더 잘 집중할 수 있게 된다.
- 객체를 테이블에 매핑하는 과정을 원하는 대로 제어할 수 있어서 DB 스키마를 단순화할 수 있다.
- 저장소 계층에 ORM을 사용하면 필요할 때 MySQL과 Postgres와 같은 다른 데이터베이스로 쉽게 전환할 수 있다.
저장소 계층의 단점
- 저장소 계층이 없더라도 ORM은 모델과 저장소의 결합도를 충분히 완화시켜줄 수 있다.
➡️ ORM이 없을 때 대부분의 코드는 Raw Query로 작성되어 있기 때문이다.
- ORM 매핑을 수동으로 하려면 개발 코스트가 더욱 소모된다.
➡️ 여기서 설명하는 ORM은 이전에 사용한 Prisma와 같은 라이브러리를 말한다. - Express로 구현하는 저장소 계층
- 게시글 API 추가하기 요구사항
- 답안 확인하기
5.7 테스트 코드(Test Code)
01. 테스트 코드에 대해 알아보기
- 테스트 코드가 무엇일까요?
테스트 코드(Test Code)라는 것이 조금은 생소하죠?
이건 여러분이 개발한 코드가 여러분이 의도한 대로 동작하는지 작성하는 코드입니다!
내가 스스로 잘했는지 체크하기 위해 만들어두는 체크리스트와 비슷해요! - 테스트 코드의 종류에 대해 알아보기
- 단위 테스트 (Unit Test)
: 가장 작은 규모의 기능을 테스트합니다.
- 통합 테스트 (Integration Test)
: 다양한 기능을 합쳤을 때 생기는 문제를 방지하기 위한 테스트입니다.
- E2E 테스트 (End-to-end Test)
: 끝에서 끝(종단 간)을 의미하는 End to end 테스트입니다.
쉽게 말하면 백엔드부터 시작해서 최종적으로 웹 페이지가 원하는 대로 데이터를 잘 보여주는지 확인합니다. - 테스팅 프레임워크 Jest에 대해 알아보기
페이스북에서 개발한 테스팅 프레임워크
왜 굳이 Jest를 써야 할까요?
- 페이스북에서 개발한 프론트엔드 라이브러리인 React.js와도 궁합이 아주 좋기 떄문에 엄청난 성장세를 보이며 2022년 기준 JavaScript 개발자들 사이에서 가장 많이 사용되는 테스팅 프레임워크로 뽑혔습니다.
왜 인기가 많은 건데요?
- 테스트 코드의 표현이 다른 프레임워크보다 훨씬 간결하다. - Jest를 실제로 사용해볼 준비!
02. Jest로 간단한 단위 테스트 코드 작성해보기 (1)
- 단위 테스트 코드 파일 생성
- 단위 테스트 코드 작성
- 단위 테스트 코드 요구사항
- 테스트 코드 실행
- 테스트 코드가 통과하도록 isEmail 함수 코드 디버깅
03. Jest로 간단한 단위 테스트 코드 작성해보기 (2)
- 테스트 코드가 실패할 수 있도록 단위 테스트 코드 추가 작성
- isEmail 함수 다시 디버깅
5.8 유닛 테스트(Unit Test)
01. [Layered Architecture Pattern] Jest 설정하기
- Layered Architecture Pattern 테스트 코드 시작하기
- Jest Configs 설정하기
- Jest Scripts 설정하기
- Jest CLI Options
- 자주 사용하는 Jest 문법 정리하기
- Mock Functions
Mock은 특정 메서드나 함수를 Mocking하기 위해 사용된다.
즉, 테스트에서 시간 또는 비용이 많이 들거나, 의존성이 높은 코드를 직접 실행하지 않고 호출 여부, 입력한 값의 일치 여부와 같은 정보를 확인하기 위해 사용하는 가짜 객체이다.
02. [Layered Architecture Pattern] 유닛 테스트
- Prisma 의존성 주입하기 (DI: Dependency Injection)
의존성 주입(DI : Dependency Injection)이란 객체 사이의 의존 관계를 외부에서 제공하는 방법을 의미한다.
즉, 하나의 객체가 다른 객체에게 의존성을 제공하는 방법을 뜻한다.
03. [Layered Architecture Pattern] 유닛 테스트 - Repository
- Repository Layer 단위 테스트 (UnitTest)
04. [Layered Architecture Pattern] 유닛 테스트 - Service
- Service Layer 단위 테스트 (UnitTest)
05. [Layered Architecture Pattern] 유닛 테스트 - Controller
- Controller 단위 테스트 (UnitTest)
- 개발자로서 성장하고 싶은 분들을 위한 조언
'Coding > 내일배움캠프' 카테고리의 다른 글
| [내일배움캠프] Node.js 4기 TIL | Day 51 | 24.02.22.(목) (0) | 2024.02.22 |
|---|---|
| [내일배움캠프] Node.js 4기 TIL | Day 50 | 24.02.21.(수) (0) | 2024.02.22 |
| [내일배움캠프] 5.1 객체 지향 프로그래밍 (OOP) - Node.js 4기 TIL | Day 48 | 24.02.19.(월) (0) | 2024.02.19 |
| [내일배움캠프] Node.js 4기 TIL | Day 47 | 24.02.18.(일) (0) | 2024.02.18 |
| [내일배움캠프] Node.js 4기 TIL | Day 46 | 24.02.17.(토) (0) | 2024.02.17 |
