ASP.NET Core를 사용한 깨끗한 아키텍처의 출발점. Clean Architecture는 같은 느슨하게 결합 된 종속성으로 인한 아키텍처에 대한 일련의 이름 중 최신 이름입니다. 또한 육각형, 포트 및 어드웨이터 또는 양파 아키텍처라는 이름도 있습니다.
Nimblepros의 Clean Architecture Course를 소개하는 Clean Architecture 및이 템플릿에 대해 자세히 알아보십시오. Code Ardalis를 사용하여 20%를 절약하십시오.
이 아키텍처는 Steve Smith와 Julie Lerman의 DDD 기초 과정에서 사용됩니다.
? Clean Architecture 또는 DDD 교육 및/또는 팀의 구현 지원은 Steve의 회사 인 Nimblepros에 문의하십시오.
Nimblepros 트레이너의 깨끗한 건축물을 구현하는 방법에 대해 알아보십시오. Sarah "Sadukie"Dutkiewicz와 Steve "Ardalis"Smith.
이 프로젝트를 좋아하거나 사용하여 솔루션을 배우거나 시작하는 경우 별을주십시오. 감사해요!
또는 당신이 정말로 관대하다고 느끼고 있다면, 우리는 이제 Github 스폰서 십을 지원합니다 - 위의 버튼을 참조하십시오.
Amazon AWS의 Foss Fund 가이 프로젝트에 12 개월간 후원을 받기로 선택했다고 발표합니다. 감사합니다. 다른 과거와 현재 후원자 덕분에 감사합니다!
기본적으로 사이트는 HTTPS를 사용하며 LocalHost 사용을 위해 자체 서명 된 개발자 인증서가있을 것으로 기대합니다. Chrome에 오류가 발생하면 완화 지침에 대해서는이 답변을 참조하십시오.
메인 브랜치는 이제 .NET 9를 사용하고 있습니다. 이것은 Nuget 패키지 버전 10.x에 해당합니다. 이전 버전을 사용할 수 있습니다 - 릴리스를 참조하십시오.
이 템플릿을 사용하려면 몇 가지 옵션이 있습니다.
dotnet new (권장)를 사용하여 설치먼저 Nuget (https://www.nuget.org/packages/ardalis.cleanarchitecture.template/)에서 템플릿을 설치하십시오.
dotnet new install Ardalis.CleanArchitecture.Template -? 옵션:
dotnet new clean - arch - ?
ASP.NET Clean Architecture Solution (C # )
Author: Steve Smith @ardalis , Erik Dahl
Usage:
dotnet new clean - arch [ options ] [ template options ]
Options:
- n , -- name < name > The name for the output being created. If no name is specified , the name of the output
directory is used.
- o , -- output < output > Location to place the generated output.
-- dry - run Displays a summary of what would happen if the given command line were run if it would result
in a template creation.
-- force Forces content to be generated even if it would change existing files.
-- no - update-check Disables checking for the template package updates when instantiating a template.
-- project < project > The project that should be used for context evaluation.
- lang , -- language < C # > Specifies the template language to instantiate.
-- type < project > Specifies the template type to instantiate.
Template options:
-as , -- aspire Include .NET Aspire.
Type: bool
Default : false dotnet new list 의 템플릿 목록에 템플릿이 성공적으로 설치된 후 표시됩니다. "Clean-Arch"라는 짧은 이름으로 "ASP.NET Clean Architecture Solution"을 찾으십시오.
솔루션 폴더를 생성하려는 부모 디렉토리로 이동하십시오.
이 명령을 실행하여 하위 폴더 이름 Your.ProjectName 솔루션 구조를 작성하십시오.
dotnet new clean-arch -o Your.ProjectName
Your.ProjectName 디렉토리 및 솔루션 파일이 생성되며 내부에는 새로운 솔루션 컨텐츠가 적절하게 네임 스패닝되어 실행/테스트 준비가됩니다!
예: 
이 작업을 수행하는 데 도움을 주신 @dahlsailrunner에게 감사드립니다!
알려진 문제 :
버전 9 에서이 솔루션 템플릿에는 FastendPoints 라이브러리를 사용한 API 엔드 포인트에 대한 지원 만 포함됩니다. 내 ApiendPoints 라이브러리, 면도기 페이지 및/또는 컨트롤러를 사용하려면 버전 7.1을 포함하는 마지막 템플릿을 사용할 수 있습니다. 또는 설치 후이 템플릿에 쉽게 추가됩니다.
FastendPoints 대신 Ardalis.apiendpoints를 사용하려면 참조를 추가하고 문서의 기본 클래스를 사용하십시오.
dotnet add package Ardalis.ApiEndpoints컨트롤러에 대한 지원을 Program.cs 파일에 추가해야합니다. 필요 :
builder . Services . AddControllers ( ) ; // ControllersWithView if you need Views
// and
app . MapControllers ( ) ;이 경우 컨트롤러 폴더를 만들 수 있고 (선택적으로)보기 폴더를 만들 수 있으며 모든 것이 예상대로 작동해야합니다. 개인적으로 나는 Razor 페이지가 컨트롤러와보기보다 훨씬 나은 것으로 나타 났으므로 Razor 페이지를 완전히 조사하지 않은 경우보기를 선택하기 전에 지금 바로 그렇게하고 싶을 것입니다.
Razor Pages에 대한 지원을 Program.cs 파일에 추가해야합니다. 필요 :
builder . Services . AddRazorPages ( ) ;
// and
app . MapRazorPages ( ) ;그런 다음 프로젝트의 루트에 페이지 폴더를 추가하고 거기에서 이동합니다.
이 저장소를 기반으로 시작하려면 사본을 로컬로 가져와야합니다. 포크, 클론 또는 다운로드의 세 가지 옵션이 있습니다. 대부분의 경우, 당신은 아마도 다운로드하고 싶을 것입니다.
리포지토리를 다운로드 하고 ZIP 파일을 차단 해제 한 후 프로젝트를 사용하려면 새 폴더로 추출하거나 응용 프로그램의 시작점으로 사용하려면 새 폴더로 추출해야합니다.
풀 요청을 제출할 계획 인 경우에만 이 저장소를 포크 해야합니다. 또는 저장소의 스냅 샷 사본을 자신의 GitHub 계정에 보관하려면.
기고자 중 하나이고이를 이용할 수있는 경우이 저장소를 복제 해야합니다. 그렇지 않으면 다른 옵션 중 하나를 원할 것입니다.
이 템플릿을 사용하기 위해이 작업을 수행 할 필요는 없지만 인프라 프로젝트에서 마이그레이션을 올바르게 설정하려면 마이그레이션 명령을 실행할 때 해당 프로젝트 이름을 지정해야합니다.
Visual Studio에서 패키지 관리자 콘솔을 열고 Add-Migration InitialMigrationName -StartupProject Your.ProjectName.Web -Context AppDbContext -Project Your.ProjectName.Infrastructure 실행하십시오.
CLI가있는 터미널에서 명령은 비슷합니다. 웹 프로젝트 디렉토리에서 이것을 실행하십시오.
dotnet ef migrations add MIGRATIONNAME - c AppDbContext - p .. / Your.ProjectName.Infrastructure / Your.ProjectName.Infrastructure.csproj - s Your.ProjectName.Web.csproj - o Data / Migrations sqlserver를 사용하려면 options.UseSqlite(connectionString)); options.UseSqlServer(connectionString)); Your.ProjectName.Infrastructure.StartupSetup 파일에서 또한 데이터베이스 서버를 가리키는 Your.ProjectName.Web.Program 파일의 DefaultConnection 으로 SqliteConnection 바꾸는 것을 잊지 마십시오.
데이터베이스를 업데이트하려면 웹 프로젝트 폴더 에서이 명령을 사용합니다 ( Clean.Architecture 프로젝트 이름으로 바꾸십시오) :
dotnet ef database update - c AppDbContext - p .. / Clean .Architecture.Infrastructure / Clean .Architecture.Infrastructure.csproj - s Clean .Architecture.Web.csproj이 저장소의 목표는 .NET Core를 사용하여 도메인 구동 설계 (DDD) 기반 또는 단순히 잘 알고있는 견고한 응용 프로그램을 구축하는 데 사용할 수있는 기본 솔루션 구조를 제공하는 것입니다. 이 주제에 대해 자세히 알아보십시오.
단일 프로젝트 또는 기존 UI-> 비즈니스 계층 -> 데이터 액세스 계층 "N -Tier"아키텍처를 따르는 일련의 프로젝트로 응용 프로그램을 구축하는 데 익숙한 경우이 두 과정을 확인하는 것이 좋습니다 (DDD 기초 이전).
Steve Smith는 또한 Microsoft의 참조 응용 프로그램, EshoponWeb 및 관련 무료 전자 책을 유지합니다. 여기에서 확인하십시오.
이 프로젝트 및 저장소의 목표는 샘플 또는 참조 응용 프로그램을 제공 하지 않습니다 . 그것은 단지 템플릿이되기위한 것이지만 실제 솔루션을 설정할 때 물건이 속한 위치를 보여줄 수있는 충분한 조각이 있습니다. 쓸모없는 "class1.cs"대신 몇 가지 실제 클래스가 있습니다. 왜 그들이 거기에있는 이유와 자신의 비슷한 파일을 넣어야하는지 이해하자마자 삭제하십시오. /sample 폴더에는 샘플 응용 프로그램이 있습니다 .
이 스타터 키트를 사용하여 Domain-Driven Design 개념 및 패턴을 사용하여 ASP.NET Core의 기본 사항을 한동안 가르쳤습니다 (ASP.NET Core가 여전히 사전 릴리스에있을 때 시작). 일반적으로 나는 Devintersection과 같은 이벤트 또는 최신 개발 기술 및 기술로 속도를 높이고 자하는 회사를위한 사립 현장 워크샵에 앞서 1 일 또는 이틀 실습 워크샵을 가르칩니다. 다가오는 워크샵에 대한 정보를 원하시면 저에게 연락하십시오.
이 솔루션 템플릿의 목표는 새로운 프로젝트를위한 상당히 베어 밴드 스타터 키트를 제공하는 것입니다. 특정 엔터프라이즈 애플리케이션이 혜택을받을 수있는 모든 가능한 프레임 워크, 도구 또는 기능이 포함되어 있지 않습니다. 데이터 액세스와 같은 기술 선택은 Microsoft의 기술 스택을 사용하는 대부분의 비즈니스 소프트웨어 개발자에게 가장 일반적이고 접근 가능한 기술에 뿌리를두고 있습니다. 로깅, 모니터링 또는 분석과 같은 것들에 대한 광범위한 지원은 포함되지 않지만 모두 쉽게 추가 할 수 있습니다. 아래는 포함 된 기술 종속성 목록과 선택한 이유입니다. 이 아키텍처의 특성은 모듈성과 캡슐화를 지원하는 것이기 때문에 대부분의 선택 기술을 위해 쉽게 교체 할 수 있습니다.
사용자 입력의 검증은 모든 소프트웨어 응용 프로그램의 요구 사항입니다. 문제는 간결하고 우아한 방식으로 그것을 구현하는 것이 어디에 의미가 있습니까? 이 솔루션 템플릿에는 4 개의 별도 프로젝트가 포함되어 있으며, 각 프로젝트는 각각 검증을 수행하고 비즈니스 불변성을 시행하는 데 책임이있을 수 있습니다 (이미 검증이 발생했을 때 일반적으로 예외로 모델링됩니다).
도메인 모델 자체는 일반적으로 객체 지향 설계에 의존하여 항상 일관된 상태에 있는지 확인해야합니다. 그것은 캡슐화를 활용하고이를 달성하기 위해 공공 상태 돌연변이 액세스를 제한하며, 그에 전달 된 주장이 이미 검증되었다고 가정하므로 대부분의 경우 검증 결과가 아닌 널 또는 기타 부적절한 값은 수익률 예외를 얻습니다.
사용 사례 / 응용 프로그램 프로젝트에는 시스템이 지원하는 모든 명령 및 쿼리 세트가 포함되어 있습니다. 자체 명령 및 쿼리 객체를 검증하는 것은 종종 책임이 있습니다. 이것은 MediaTr 행동 또는 다른 파이프 라인을 통해 책임 패턴을 사용하여 가장 쉽게 수행됩니다.
웹 프로젝트에는 RER 패턴에 따른 자체 요청 및 응답 유형을 포함하는 모든 API 엔드 포인트가 포함되어 있습니다. FastendPoints 라이브러리에는 요청 유형에 대한 fluentvalidation을 사용한 유효성 검사에 대한 내장 지원이 포함되어 있습니다. 이것은 입력 검증을 수행 할 수있는 자연스러운 장소입니다.
유효성 검사는 API 엔드 포인트 내에서 발생하고 유스 케이스 레벨에서 다시 중복으로 간주 될 수 있습니다. 두 곳에서 본질적으로 동일한 유효성 검사를 추가하는 데는 트레이드 오프가 있습니다. 하나는 API 요청과 다른 하나는 사용 케이스 핸들러로 전송됩니다. 방어 코딩 후에는 오버 헤드가 최소화되고 마음의 평화와 더 큰 응용 강력성이 종종 그만한 가치가 있기 때문에 종종 두 곳에서 검증을 추가하는 것이 합리적입니다.
핵심 프로젝트는 깨끗한 아키텍처 설계의 중심이며 다른 모든 프로젝트 종속성은이를 향해 지적해야합니다. 따라서 외부 의존성이 거의 없습니다. 핵심 프로젝트에는 다음과 같은 것들을 포함한 도메인 모델이 포함되어야합니다.
이러한 패턴과 적용하는 방법에 대해 자세히 알아볼 수 있습니다.
선택적인 프로젝트, 나는 많은 사람들이 그것을 요구하고 있었고 나중에 추가하는 것보다 제거하기가 더 쉽기 때문에 그것을 포함시켰다. 이것은 종종 응용 프로그램 또는 응용 프로그램 서비스 계층이라고도합니다. 사용 사례 프로젝트는 CQRS에 따라 명령 및 쿼리로 구성되어 있습니다 ( Commands 및 Queries 용 폴더가있는 것을 고려했지만 거의 추가되지 않았다고 생각했습니다. 실제 명령 또는 쿼리 당 폴더는 여분의 중첩없이 충분합니다). 명령은 도메인 모델을 돌연변이하므로 항상 데이터 액세스에 리포지토리 추상화를 사용해야합니다 (저장소는 도메인 모델 유형을 가져오고 지속하는 방법입니다). 쿼리는 준비 적으로 사용되므로 저장소 패턴을 사용할 필요가 없지만 대신 가장 편리한 쿼리 서비스 나 접근 방식을 사용할 수 있습니다.
사용 사례 프로젝트는 핵심에 의존하도록 설정되었으며 인프라에 의존하지 않으므로 데이터 액세스에 대한 추상화가 여전히 정의되어야합니다. 또한 사양과 같은 것을 사용할 수 있으며 , 때로는 쿼리 로직을 캡슐화하고 결과 유형 매핑을 캡슐화하는 데 도움이 될 수 있습니다. 그러나 저장소/사양을 사용할 필요는 없습니다. 데이터를 얻는 가장 효율적인 방법 인 경우 SQL 쿼리를 발행하거나 저장 프로 시저를 호출 할 수 있습니다.
이 프로젝트를 포함 할 수있는 선택적 프로젝트 (API 엔드 포인트는 도메인 모델 또는 쿼리 서비스와 직접 작동합니다)이지만 자동 테스트를 추가 할 수있는 멋진 UI-inorant 장소를 제공하며 메시지 핸들러 주변의 책임 패턴을 사용하여 문제를 해결하기위한 정책을 적용하는 데 적합합니다 (검증, 캐싱, 인증 등, 인증, 타이밍 등). 템플릿에는 SharedKernel Nuget 패키지에있는 로깅의 예제가 포함되어 있습니다.
외부 리소스에 대한 응용 프로그램 의존성의 대부분은 인프라 프로젝트에 정의 된 클래스에서 구현해야합니다. 이 클래스는 코어에 정의 된 인터페이스를 구현해야합니다. 의존성이 많은 프로젝트가 매우 큰 경우 여러 인프라 프로젝트 (예 : Infrastructure.data)를 갖는 것이 합리적 일 수 있지만 대부분의 프로젝트의 경우 폴더가있는 하나의 인프라 프로젝트가 제대로 작동합니다. 템플릿에는 데이터 액세스 및 도메인 이벤트 구현이 포함되어 있지만이 프로젝트에 이메일 제공 업체, 파일 액세스, 웹 API 클라이언트 등과 같은 것들을 추가하여 코어 또는 UI 프로젝트에 커플 링을 추가하지 않습니다.
응용 프로그램의 진입 점은 ASP.NET Core Web Project (또는 AspireHost 프로젝트가 웹 프로젝트를로드 할 수 있음)입니다. 이것은 실제로 Program.cs 의 public static void Main 메소드가있는 콘솔 응용 프로그램입니다. 패스트 렌지 포인트와 repr 패턴을 활용하여 API 엔드 포인트를 구성합니다.
공유 커널은 경계 컨텍스트 사이의 공통 요소를 공유하는 데 사용됩니다. DDD 용어이지만 많은 조직이 여러 응용 프로그램간에 공유하는 데 유용한 "일반적인"프로젝트 또는 패키지를 활용합니다.
여러 경계 컨텍스트간에 코드를 공유 해야하는 경우 별도의 SharedKernel 프로젝트 및 솔루션을 작성하는 것이 좋습니다 (DDD 기초 참조). 또한 이것을 NUGET 패키지 (대부분의 조직 내에서 개인적으로)로 게시하고 필요한 프로젝트에 의해 Nuget 의존성으로 언급하는 것이 좋습니다.
이전에는 SharedKernel의 프로젝트 가이 프로젝트에 포함되었습니다. 그러나 위의 이유로 인해 별도의 패키지 인 Ardalis.sharedKernel을 만들었습니다. 이 템플릿을 사용할 때 직접 교체해야합니다 .
SharedKernel 패키지의 또 다른 예를 보려면 업데이트 된 pluralsight DDD 코스에 사용하는 패키지는 여기 Nuget에 있습니다.
테스트 프로젝트는 테스트 종류 (단위, 기능, 통합, 성능 등) 또는 테스트중인 프로젝트 (핵심, 인프라, 웹) 또는 둘 다를 기반으로 구성 할 수 있습니다. 이 간단한 스타터 키트의 경우 테스트 프로젝트는이 솔루션에 존재하는 단위, 기능 및 통합 테스트 프로젝트와 함께 테스트 종류를 기반으로 구성됩니다. 기능 테스트는 실제로 실제 웹 사이트를 호스팅하거나 네트워크를 진행하지 않고 웹 프로젝트의 API에 대한 피하 테스트를 수행하는 특별한 종류의 통합 테스트입니다. 이런 종류의 테스트를 더 짧고 유지하기가 쉽게하기 위해 많은 테스트 헬기를 만들었습니다.
이 솔루션 템플릿에는 몇 가지 일반적인 패턴, 특히 도메인 구동 설계 패턴을 지원하기위한 코드가 내장되어 있습니다. 다음은 몇몇이 어떻게 작동하는지에 대한 간단한 개요입니다.
도메인 이벤트는 구현에서 작동을위한 트리거를 분리하기위한 훌륭한 패턴입니다. 이벤트 핸들러는 종속성을 가질 수 있고 엔티티 자체는 일반적으로 그렇지 않기 때문에 도메인 엔티티 내에서 특히 유용합니다. 샘플에서는 ToDoItem.MarkComplete() 메소드 로이 기능을 볼 수 있습니다. 다음 시퀀스 다이어그램은 웹 API 엔드 포인트를 통해 항목이 완성 될 때 이벤트와 핸들러가 어떻게 사용되는지 보여줍니다.
