nextjs clean architecture

다음에 깨끗한 아키텍처

이 repo는 Next.js에서 깨끗한 아키텍처를 달성하는 방법의 예입니다. 이 프로젝트를 진행하는 비디오 자습서가 있습니다. YouTube에서 확인하려면 이미지를 클릭하십시오.

npm install 및 npm run dev 실행하여 프로젝트를 실행할 수 있습니다.

깨끗한 건축

메모

? 원래 클린 아키텍처 다이어그램의 단순화 된 버전을 그렸습니다. 나는 나에게 더 합리적 인 방식으로 그것을 단순화했으며 이해하기가 더 쉽습니다. 나는 그것이 당신도 도움이되기를 바랍니다.

Clean Architecture에 대해 처음 듣는 경우 Bob 삼촌의 원본 기사를 읽어 보는 것이 좋습니다. 그러나 아래에서 요약하겠습니다.

Clean Architecture는 응용 프로그램이 유지 관리 및 테스트가 쉽고 테스트하기가 쉽고 코드베이스를 예측할 수있는 방식으로 구조화하는 데 도움이되는 일련의 규칙 입니다. 그것은 기술적 배경과 프로그래밍 언어 선호도에 관계없이 개발자가 이해하는 공통 언어와 같습니다.

깨끗한 아키텍처 및 유사한/파생 아키텍처는 모두 동일한 목표 - 우려 사항을 분리합니다 . 그들은 비슷한 코드를 함께 묶는 계층을 소개합니다. "레이어링"은 코드베이스에서 중요한 측면을 달성하는 데 도움이됩니다.

• UI와 무관하게 - 비즈니스 로직은 사용되는 UI 프레임 워크 (이 경우 다음 : JS)와 결합되지 않습니다. 비즈니스 로직 또는 규칙을 변경하지 않고도 동일한 시스템을 CLI 응용 프로그램에서 사용할 수 있습니다.
• 데이터베이스와 무관하게 - 데이터베이스 구현/운영은 자체 계층에서 격리되어 있으므로 나머지 앱은 사용중인 데이터베이스가 어떤 데이터베이스를 사용하는지 신경 쓰지 않고 모델을 사용하여 통신합니다.
• 프레임 워크와 무관하게 - 비즈니스 규칙과 논리는 단순히 외부 세계에 대해 아무것도 모른다. 일반 JavaScript로 정의 된 데이터를 수신하고 일반 JavaScript, 서비스 및 리포지토리를 사용하여 자신의 논리와 기능을 정의합니다. 이를 통해 시스템을 구현 및 제한으로 "형성"하지 않고 프레임 워크를 도구로 사용할 수 있습니다. 앱에서 경로 처리기를 사용하고 서버 작업에 일부를 리팩터링하려는 경우 경로 처리기 대신 서버 작업에서 특정 컨트롤러를 호출하는 것만 큼해야하지만 핵심 비즈니스 로직은 변경되지 않았습니다.
• 테스트 가능 - 비즈니스 로직 및 규칙은 UI 프레임 워크, 데이터베이스, 웹 서버 또는 시스템을 구축하는 기타 외부 요소에 의존하지 않기 때문에 쉽게 테스트 할 수 있습니다.

클린 아키텍처는 종속성 계층 구조를 정의함으로써이를 달성합니다. 레이어는 그 아래의 레이어에만 의존하지만 위에 있지는 않습니다.

프로젝트 구조 (중요한 비트 만)

• app - 프레임 워크 및 드라이버 레이어 - 기본적으로 다음 모든 것 (페이지, 서버 동작, 구성 요소, 스타일 등) 또는 앱의 논리를 "소비"합니다.
• di 종속성 주입 - DI 컨테이너와 모듈을 설정하는 폴더
• drizzle - 모든 DB- DB 클라이언트 초기화, 스키마 정의, 마이그레이션
• src 시스템의 "루트"
  • application - 애플리케이션 계층 - 저장소 및 서비스를위한 사용 사례 및 인터페이스를 보유합니다.
  • entities - 엔터티 레이어 - 모델 및 사용자 정의 오류를 보유합니다.
  • infrastructure - 인프라 계층 - 리포지토리 및 서비스 구현을 보유하고 application 에서 인터페이스를 가져옵니다.
  • interface-adapters - 인터페이스 어댑터 레이어 - 시스템의 진입 점으로 사용되는 컨트롤러를 보유합니다 (시스템과 상호 작용하기 위해 프레임 워크 및 드라이버 계층에 사용됨)
• tests - 단위 테스트는 여기에 살고 있습니다 - unit 하위 폴더의 구조는 src 와 일치합니다.
• .eslintrc.json eslint-plugin-boundaries 플러그인이 정의되는 곳 - 종속성 규칙을 위반하는 것을 막을 수 있습니다.
• vitest.config.ts @ alias가 정의되는 방법에 유의하십시오!

레이어 설명

• 프레임 워크 및 드라이버 : 모든 UI 프레임 워크 기능과 시스템과 상호 작용하는 모든 것을 유지합니다 (예 : AWS Lambdas, Stripe Webhooks 등). 이 시나리오에서는 다음입니다. JS Route 핸들러, 서버 작업, 구성 요소 (서버 및 클라이언트), 페이지, 디자인 시스템 등 ...
  • 이 계층은 컨트롤러 , 모델 및 오류 만 사용해야하며 사용 사례 , 저장소 및 서비스를 사용 해서는 안됩니다 .
• 인터페이스 어댑터 : 컨트롤러 정의 :
  • 컨트롤러는 입력을 특정 사용 사례에 전달하기 전에 인증 검사 및 입력 유효성 검사를 수행합니다.
  • 컨트롤러는 사용 사례를 조정합니다 . 논리를 구현하지는 않지만 사용 사례를 사용하여 전체 작업을 정의합니다.
  • 더 깊은 층의 오류가 거품이 켜지고 컨트롤러가 사용되는 곳에서 처리됩니다.
  • 컨트롤러는 발표자를 사용하여 데이터를 "소비자"로 되돌리기 직전에 데이터를 UI 친화적 인 형식으로 변환합니다. 이를 통해 클라이언트 (데이터 변환을위한 논리 및 라이브러리)에 자바 스크립트를 적게 배송하고 이메일이나 해시 암호와 같은 민감한 속성이 유출되는 것을 방지하고 고객에게 다시 보내는 데이터의 양을 낮추는 데 도움이됩니다.
• 응용 프로그램 : 비즈니스 논리가 사는 곳. 때로는 핵심 이라고합니다. 이 레이어는 서비스 및 리포지토리의 사용 사례 및 인터페이스를 정의합니다.
  • 사용 사례 :
    • "Todo 만들기"또는 "로그인"또는 "토글 토드"와 같은 개별 작업을 나타냅니다.
    • 사전 검증 된 입력 (컨트롤러에서)을 수락하고 허가 확인을 처리하십시오 .
    • 저장소 및 서비스를 사용하여 데이터 소스에 액세스하고 외부 시스템과 통신하십시오.
    • 사용 사례는 다른 사용 사례를 사용해서는 안됩니다 . 그것은 코드 냄새입니다. 이는 유스 케이스가 여러 가지 일을하고 여러 사용 사례로 분류되어야한다는 것을 의미합니다.
  • 저장소 및 서비스를위한 인터페이스 :
    • 이들은 도구 및 프레임 워크 (데이터베이스 드라이버, 이메일 서비스 등)의 종속성을 해제하려고하므로 인프라 계층에서 구현 하므로이 계층에 정의됩니다.
    • 인터페이스는이 레이어에 실시되므로 사용 사례 (및 전기적으로 상단 계층)는 종속성 주입을 통해 이들을 액세스 할 수 있습니다.
    • 의존성 주입을 통해 구현 (클래스)에서 정의 (인터페이스)를 분할하고 별도의 계층 (인프라)에 보관할 수 있지만 여전히 사용을 허용합니다.
• 엔티티 : 모델 과 오류가 정의되는 경우.
  • 모델 :
    • "데이터베이스"기술을 사용하지 않고 일반 JavaScript로 "도메인"데이터 형태를 정의하십시오.
    • 모델은 항상 데이터베이스에 연결된 것은 아닙니다. 전자 메일을 보내려면 데이터베이스가 아닌 외부 이메일 서비스가 필요하지만 다른 레이어가 "이메일 보내기"를 전달하는 데 도움이되는 데이터 모양이 필요합니다.
    • 모델은 또한 "엔터프라이즈 비즈니스 규칙"이라고하는 자체 검증 규칙을 정의합니다. 외부 가 변경 될 때 일반적으로 변경되지 않거나 변경 될 가능성이 가장 낮은 규칙 (페이지 탐색, 보안 등). 예로는 6 자 이상이어야하고 특수 문자를 포함하지 않는 사용자 이름 필드를 정의하는 User 모델이 있습니다.
  • 오류 :
    • 데이터베이스 별 오류 또는 라이브러리 또는 프레임 워크에 특정한 모든 유형의 오류를 원하지 않기 때문에 우리는 자신의 오류를 원합니다.
    • 우리는 다른 라이브러리 (예 : 이슬비)에서 나오는 오류를 catch 하고 해당 오류를 우리 자신의 오류로 변환합니다.
    • 이것이 바로 우리의 핵심을 핵심을 유지할 수있는 방법입니다. 모든 프레임 워크, 라이브러리 및 기술 (깨끗한 아키텍처의 가장 중요한 측면 중 하나) 중 하나입니다.
• 인프라 : 저장소 및 서비스 가 정의되는 곳.
  • 이 레이어는 애플리케이션 레이어 에서 저장소 및 서비스의 인터페이스를 끌어 내고 자체 클래스에서 구현합니다.
  • 저장소는 데이터베이스 작업을 구현하는 방법입니다. getTodo , createTodo 또는 updateTodo 와 같은 단일 데이터베이스 작업을 수행하는 방법을 노출시키는 클래스입니다. 이는이 클래스에서만 데이터베이스 라이브러리 / 드라이버를 사용한다는 것을 의미합니다. 데이터 검증을 수행하지 않고 데이터베이스에 대한 쿼리 및 돌연변이를 실행하고 사용자 정의 된 오류 또는 반환 결과를 던지십시오.
  • 서비스는 인증 서비스 나 이메일 서비스와 같이 응용 프로그램 전반에 걸쳐 사용되는 공유 서비스입니다. 또는 Stripe (지불, 영수증 검증 등)와 같은 외부 시스템을 구현합니다. 이 서비스는 또한 다른 프레임 워크 및 라이브러리를 사용하고 의존합니다. 그렇기 때문에 구현이 저장소와 함께 여기에 보관됩니다.
  • 우리는 어떤 계층 이이 계층에 의존하기를 원하지 않기 때문에 (그리고 데이터베이스와 모든 서비스에 전적으로 의존) 종속성 반전 원칙을 사용합니다. 이를 통해 인프라 계층의 구현 대신 응용 프로그램 계층 에 정의 된 인터페이스에만 의존 할 수 있습니다. 우리는 ioctopus와 같은 제어 라이브러리의 반전을 사용하여 인터페이스 뒤의 구현을 추상화하고 필요할 때마다 "주입"합니다. di 디렉토리에서 추상화를 만듭니다. 우리는 저장소, 서비스, 컨트롤러 및 사용 사례를 기호로 "바인딩"하며 실제 구현이 필요할 때 해당 기호를 사용하여 "해결"합니다. 그것이 구현을 명시 적으로 의존하지 않고도 구현을 사용할 수있는 방법입니다 (가져 오기).

FAQ

팁

FAQ가 다루지 않는 질문이있는 경우이 리포지어에서 문제를 열거 나 Discord 서버에 가입하여 대화를 시작하십시오.

Clean Architecture /이 구현 서버 친화적입니까? 이것을 Vercel에 배포 할 수 있습니까?

예! 페이지 라우터, 앱 라우터, 미들웨어, API 핸들러, 서버 작업 등을 사용할 수 있습니다! 일반적으로 JavaScript 프로젝트에서 의존성 주입을 달성하는 것은 Node를 제외한 다른 런타임과 호환되지 않는 Inversify.js 라이브러리를 사용하여 수행됩니다. 이 프로젝트는 reflect-metadata 에 의존하지 않고 모든 런타임에서 작동하는 간단한 IOC 컨테이너 인 ioctopus를 구현합니다.

다음에 다음.js 프로젝트를 만들 때 즉시 깨끗한 아키텍처를 구현해야합니까?

나는 아니오라고 말하고 싶다. 새로운 프로젝트를 시작하는 경우 가능한 한 빨리 MVP 상태를 달성하는 데 집중하는 것이 좋습니다 (따라서 아이디어를 검증 / 프로젝트의 미래가 있는지 확인할 수 있습니다). 상황이 심각해지기 시작하면 (더 많은 기능이 구현되기 시작하거나, 사용자 기반이 상당한 성장을 경험하거나 프로젝트의 다른 개발자를 탑승시키고 있음),이 아키텍처 (또는 해당 문제에 대한 아키텍처)를 조정하는 데 시간을 투자하고 싶을 때입니다.

이미 프로젝트의 잡초에 깊은 곳이 있다면, 귀하와 팀은 다음 스프린트에서 시작하여 점진적인 리팩토링을 계획 할 수 있습니다. 이 경우 이미 코드가 작성되었으며, 코드를 조금만 재구성하면 코드를 조금만 재구성하면 Route Handler를 통해 경로 처리기, 서버 작업에 의한 서버 작업을 부분적으로 수행 할 수 있습니다. 그건 그렇고, 나는 그것을 가볍게 "조금만 재구성해야한다"고 말하지만, 그다지 단순한 것과는 거리가 멀다. 리팩토링을 계획 할 때 항상 "잘못되는 것"을 고려하십시오. 그리고 테스트를 작성하는 데 시간을 투자하십시오!

이것은 과도하게 가방처럼 보이고 기능 개발을 복잡하게 만듭니다.

이에 대해 생각하면 3 분 이상을 쓰지 않으면 그렇습니다. 그러나 그렇게한다면, 건축 = 징계를 알게 될 것입니다. 아키텍처는 어디로 가는지 정의하는 개발자 간의 계약입니다. 실제로 코드베이스를 예측할 수있게하기 때문에 기능 개발을 단순화하고 그러한 결정을 내립니다.

작업하는 모든 개발자가 가장 편리한 코드를 작성하면 프로젝트를 지속적으로 성장시킬 수 없습니다. 코드베이스는 함께 일하기에 악몽으로 변할 것이며, 그때는 실제로 복잡한 기능 개발 프로세스를 느낄 것입니다. 이것에 맞서기 위해 결국에는 몇 가지 규칙을 내려 놓을 것입니다. 팀이 새로운 문제에 직면하고 해결함에 따라 이러한 규칙이 커질 것입니다. 이 모든 규칙을 문서에 넣으면 자체 아키텍처 정의가 있습니다. 당신은 여전히 일종의 아키텍처를 구현할 수 있습니다. 방금 그 지점에 매우 느리고 고통스럽게 도달했습니다.

깨끗한 아키텍처는 테스트 된 바로 가기와 사전 정의 된 아키텍처를 제공합니다. 그렇습니다. 물론이 모든 것을 배워야하지만 평생 한 번 수행 한 다음 앞으로 사용할 언어 나 프레임 워크에 원칙을 적용합니다.

모든 프로젝트에 깨끗한 아키텍처를 적용해야합니까?

아니요 . 프로젝트가 기능의 수, 사용자 수, 또는 그 작업을 수행하는 개발자 수 모두로 성장할 것으로 기대하지 않는 경우가 아닙니다.

건축을 청소하기위한 다른 유사한 아키텍처는 무엇입니까?

Readme의 상단에서 언급 한 원래 블로그 게시물에서 언급했듯이 :

• Alistair Cockburn의 육각형 건축 (일명 포트 및 어댑터)
• Jeffrey Palermo의 양파 건축
• 밥 삼촌의 비명 건축물 (깨끗한 건축물 뒤에 같은 사람)
• 그리고 몇 가지 더 (원래 블로그 게시물을 확인하십시오)