await this.postsService.findAllPosts(); 는 PostsController 클래스의 postService 인스턴스에서 findAllPost 메서드를 호출한다.
컨트롤러는 하위 계층의 내부 구조에 대해 신경쓰지 않는다. 대신, 외부에 공개된 메서드를 호출하기만 한다. 이것이 가능한 이유는 추상화( Absctraction )의 특성 덕분이다.
PostsController 클래스는 전달된 요청( Request )을 처리하기 위해 PostsService를 호출하도록 구현했다. 여기서 컨트롤러가 비즈니스 로직을 직접 수행하지 않고, 클라이언트의 요청을 서비스 계층으로 바로 전달 하도록 구현한 것을 확인 할 수 있다.
결국, PostsController 클래스는 클라이언트의 요청( Request )을 서비스 계층으로 전달하는 역할을 수행하며, 서비스 계층이 어떠한 내부 구조를 통해 비즈니스 로직을 수행하는지는 상위 계층인 컨트롤러에게는 중요하지 않다.
서비스( Service )
서비스 계층( Service Layer )
다른 이름으로는 비즈니스 로직 계층( Business logic layer )은 아키텍처의 가장 핵심적인 비즈니스 로직을 수행하고 클라이언트가 원하는 요구사항을 구현하는 계층이다.
프레젠테이션 계층( Persentation Layer )과 데이터 엑세스 계층( Data Access Layer ) 사이에서 중간 다리 역할을 하고, 서로 다른 두 계층이 직접 통신하지 않게 만들어 준다.
서비스( Service )는 데이터가 필요할 때, 저장소( Repository )에게 데이터를 요청한다.
어플리케이션의 규모가 커질수록, 서비스 계층의 역할과 코드의 복잡성도 점점 더 커지게 된다.
어플리케이션의 핵심적인 비즈니스 로직을 수행하고, 클라이언트들의 요구사항을 반영해 원하는 결과를 반환해주는 계층이다.
서비스 계층의 장단점
서비스 계층의 장점
사용자의 유즈 케이스( Use Case )와 워크플로우( Workflow )를 명확히 정의하고 이해할 수 있도록 도와준다.
비즈니스 로직이 API 뒤에 숨겨져 있으므로, 서비스 계층의 코드를 자유롭게 수정하거나 리팩터링할 수 있다.
저장소 패턴( Repository Pattern ) 및 가짜 저장소( Fake Repository )와 조합하면 높은 수준의 테스트를 작성할 수 있다.
서비스 계층의 단점
서비스 계층 또한 다른 추상화 계층이므로, 잘못 사용하면 코드의 복잡성을 증가시킬 수 있다.
한 서비스 계층이 다른 서비스 계층에 의존하는 경우, 의존성 관리가 복잡해질 수 있다.
서비스 계층에 너무 많은 기능을 넣으면 빈약한 도메인 모델( Anemic Domain Model )과 같은 안티 패턴이 생길 수 있다.
Express로 구현하는 서비스 계층
Service
사용자의 요구사항을 처리하는 핵심 부분
DB 정보가 필요할 때는 Repository에게 요청한다.
PostsController 클래스가 클라이언트의 요청( Request )을 PostsServer 클래스에게 전달하는 과정을 살펴봤다.
이번에는 서비스 계층( Service Layer )에게 비즈니스 로직을 어떻게 수행하고, 필요한 데이터를 어떻게 저장소( Repository )로부터 요청하는지 확인해보도록 하자.
posts.service.js
// src/services/posts.service.jsimport { PostsRepository } from'../repositories/posts.repository.js';
exportclassPostsService{
postsRepository = new PostsRepository();
findAllPosts = async () => {
// 저장소(Repository)에게 데이터를 요청합니다.const posts = awaitthis.postsRepository.findAllPosts();
// 호출한 Post들을 가장 최신 게시글 부터 정렬합니다.
posts.sort((a, b) => {
return b.createdAt - a.createdAt;
});
// 비즈니스 로직을 수행한 후 사용자에게 보여줄 데이터를 가공합니다.return posts.map((post) => {
return {
postId: post.postId,
nickname: post.nickname,
title: post.title,
createdAt: post.createdAt,
updatedAt: post.updatedAt,
};
});
};
createPost = async (nickname, password, title, content) => {
// 저장소(Repository)에게 데이터를 요청합니다.const createdPost = awaitthis.postsRepository.createPost(
nickname,
password,
title,
content,
);
// 비즈니스 로직을 수행한 후 사용자에게 보여줄 데이터를 가공합니다.return {
postId: createdPost.postId,
nickname: createdPost.nickname,
title: createdPost.title,
content: createdPost.content,
createdAt: createdPost.createdAt,
updatedAt: createdPost.updatedAt,
};
};
}
이번 서비스 계층( Service Layer )에서 PostsService 클래스가 PostsRepository의 findAllPosts, createPost 메서드를 호출하는 것을 확인할 수 있다. 해당 코드는 서비스가 비즈니스 로직을 수행하는 데 필요한 데이터를 저장소 계층( Repository Layer )에게 요청해 가져오는 것을 확인 할 수 있다.
또한, 서비스 계층에서는 return posts.map(post => {}); 와 같이 데이터를 가공하는 작업이 이루어진다.
만약, 저장소 계층에서 받은 데이터를 그대로 클라이언트에게 전달한다면, 사용자의 비밀번호와 같은 민감한 정보까지 노출되는 보안 문제가 발생해, 서버의 보안성이 떨어지는 결과를 낳는다.
저장소( Repository )
저장소 계층( Repository Layer )
데이터 엑세스 계층( Data Access Layer )이라고 불린다. 주로 데이터베이스와 관련된 작업을 처리하는 계층이다.
데이터 접근과 관련된 세부 사항을 숨기는 동시에, 메모리상에 데이터가 존재하는 것처럼 가정해 코드를 구현한다.
저장소 계층을 도입하면, 데이터 저장 방법을 더욱 쉽게 변경할 수 있고, 테스트 코드 작성시 가짜 저장소( Mock Repository )를 제공하기가 더 쉬워진다.
어플리케이션의 다른 계층들은 저장소의 세부 구현 방식에 대해 알지 못하더라도 해당 기능을 사용할 수 있다. 즉, 저장소 계층의 변경 사항이 다른 계층에 영향을 주지 않는 것이다. ( 객체 지향의 개념 중 추상화( Abstraction)와 관계가 있다. )
저장소 계층은 데이터 저장소를 간단히 추상화한 것으로, 이 계층을 통해 모델 계층과 데이터 계층을 명확하게 분리할 수 있다.
대표적인 저장소 계층의 메서드
add(), create() : 새 원소를 저장소에 추가한다.
get(), find() : 이전에 추가한 원소를 저장소에 가져온다.
저장소 계층의 장단점
저장소 계층의 장점
데이터 모델과 데이터 처리 인프라에 대한 사항을 분리했기 때문에 단위 테스트( Unit test )를 위한 가짜 저장소( Mock Repository )를 쉽게 만들 수 있다.
도메인 모델을 미리 작성해, 처리해야할 비즈니스 문제에 더 잘 집중할 수 있다.
객체를 테이블에 매칭하는 과정을 원하는 대로 제어할 수 있어서 DB 스키마를 단순화할 수 있다.
저장소 계층에 ORM을 사용하면 필요할 때 MySQL과 Postgre와 같은 다른 데이터베이스로 쉽게 전환할 수 있다.
저장소 계층의 단점
저장소 계층이 없더라도 ORM은 모델과 저장소의 결합도를 충분히 완화시켜 줄 수 있다. ( ORM이 없을 때 대부분의 코드는 Raw Query로 작성되어 있기 때문 )
ORM 매핑을 수동으로 하려면 개발 코스트가 더욱 소모된다. ( 여기서 설명하는 ORM은 이전에 사용한 Prisma와 같은 라이브러리를 말한다. )
Express로 구현하는 저장소 계층
Repository
데이터베이스 관리( 연결, 해제, 자원 관리 ) 역할을 담당한다.
데이터베이스의 CRUD 작업을 처리한다.
3계층 아키텍처의 마지막 계층인 저장소 계층( Repository Layer )이다.
이전에 작성했던 코드에서 서비스 계층( Service Layer )인 PostsServices에서 PostsRepository를 호출해 데이터를 요청하는 것을 확인할 수 있었다.
이번에는 저장소 계층( Repository Layer )이 어떻게 데이터베이스의 데이터를 가져와 상위 계층에게 반환하는지 확인해보도자.