NestJS는 레퍼런스가 다른 프레임워크에 비해 많이 적다. 따라서 프로젝트 디렉토리 구조도 참고할 만한 글이 거의 없는데, 이번에 좋은 글을 발견해 한 번 정리하려고 한다.
DDD - Domain-Driven Design
DDD란, 도메인 주도 설계를 뜻한다.
1) 도메인 그 자체에 초점을 맞춘다
일반적으로 많이 사용하는 데이터 중심의 접근법을 탈피해 순수한 도메인의 모델과 로직에 집중하는 것
2) 보편적인 언어의 사용
도메인 전문가와 개발자 간의 커뮤니케이션 문제를 없애기 위함이다. 동일한 표현과 단어로 구성된 모든 문서, 코드로 단일화된 언어체계를 구축해나간다.
3) 소프트웨어 entity와 도메인 컨셉을 일치시킨다
도메인 모델과 코드를 일치시키고, 같이 움직이는 구조를 지향한다.
Onion Architecture
Onion 아키텍처는 DDD의 개념을 구현한 구조다.
어떤 장점이 있을까?
도메인 엔티티는 핵심이자, 중심 부분에 있다. 핵심이자 중심인 도메인 엔티티와 비즈니스 로직 부분과 외부 종속성을 최대한 멀리, 바깥쪽으로 유지한다.
- 유연하고 지속 가능한 아키텍처를 제공
- 각 계층이 결합되어 있지 않고 관심사가 분리되어 있다.
- 각 계층은 중심 또는 안쪽 계층에 의존하므로 향상된 유지보수성
- 다른 모듈에 영향을 주지 않고, 별도 계층에 대해 단위 테스트 진행 가능
- 핵심 도메인에 영향을 주지 않고 프레임워크 또는 기술을 쉽게 변경 가능
NestJS Project Structure
위의 DDD와 Onion Architecture를 기본적으로 알아야 이해할 수 있어, 간단한 배경 지식을 알아보았다. 이제 본격적으로 NestJS 프로젝트 구조를 어떻게 구성하면 좋을지 알아보자.
핵심적인 것만 언급하면 아래와 같다.
- 통신 계층: REST Controller 또는 웹소켓용 Gateway 등
- 데이터베이스 추상화 계층: ORM Repository, Model 등
- 비즈니스 로직 계층: Service
- 액세스 제어 계층: Guard
- 데이터 유효성 검사 및 변환 계층: Pipe
- 프레젠테이션 계층: MVC 아키텍처를 사용하는 경우
Domain
개발자가 다루어야 할 도메인은 2가지다.
개발 Domain
사용 중인 프레임워크 및 언어에서 어플리케이션을 동작시키도록 만드는 방법에 대한 지식이다.
비즈니스 Domain
말그대로, 비즈니스 문제를 해결하기 위해 수행해야 하는 작업에 대한 지식이다.
그렇다면 이 2가지를 하나로 맞춰야 하는데, 사실 어렵다. 비즈니스를 개발에 맞추냐, 개발을 비즈니스에 맞추냐를 고민할 수 있지만, 이번 글에서 다루는 구조는 DDD 기반이기 때문에 비즈니스 도메인을 먼저 모델링한 후에, 개발 도메인을 맞추는 방식을 택할 것이다.
Nest의 module 은 이를 더 쉽게 해줄테니 걱정하지 말자!
블로그를 만들어보며, onion을 적용해보자
일단 블로그를 개발하려면 어떤 기능을 개발해야 하는지 먼저 생각해봐야 한다.
아마 블로그 글, 사용자, 그리고 auth 도메인이 필요할 것 같다.
management
일단 앞서 언급한 각 도메인을 관리하는 가장 높은 레벨인 management 도메인을 생성하자.
nest generate module blog
nest generate module user
nest generate module auth- 다른 도메인 이름을 가진 폴더가 생성
- 해당 이름의 모듈 파일
- 방금 생성된 모듈들은 이미 app.module.ts (root module)에 import 되어 있다.
아직은 잘 모르겠지만, 참고한 글에서는 다른 도메인은 괜찮아보이지만, 블로그 도메인 내에서는 특히 댓글 부분이 복잡해질 수도 있다 판단해, 아래와 같이 blog 폴더에서 blog 내의 도메인 관리 모듈을 또 생성한다.
nest generate module drafting
nest generate module publishing
nest generate module commenting위의 코드를 실행해 생성하면, blog 폴더 내에 또 폴더가 생성되고, module이 아래처럼 생성된다.
service
이제 도메인 내의 비즈니스 로직을 수행할 service를 생성할 차례다. 일단 auth는 login, logout, register 정도의 메서드만 필요하지만 메서드가 커질 것을 우려해 3가지로 나누어 service를 생성하지만, 사실 1가지로 생성해도 괜찮다고 생각한다.
nest generate service login
nest generate service logout
nest generate service register
모듈 시스템의 장점
- 기본적으로, 어떤 모듈이든 가져와 다른 곳에서 재사용할 수 있다.
- 강력한 DI 시스템이 제공된다.
- 기능에 문제가 있을 때 작업해야 하는 코드를 빠르게 찾을 수 있다.
- 제일 핵심적인 것은, ✨ 서비스 지향적 사고의 방향으로 이끌어 준다. ✨
개발자 도메인에만 속하는 것은?
DB에 연결하거나, Swagger를 통해 API를 생성하는 등과 같은 것들은 아래처럼 common 폴더를 생성해 모듈을 생성하면 된다.
참고
