Titik awal untuk arsitektur bersih dengan ASP.NET Core. Arsitektur bersih hanyalah yang terbaru dari serangkaian nama untuk arsitektur yang dipasangkan secara longgar dan bergantung pada ketergantungan. Anda juga akan menemukannya bernama hexagonal, port-and-adapters, atau arsitektur bawang.
Pelajari lebih lanjut tentang arsitektur bersih dan template ini dalam kursus arsitektur bersih Nimblepros. Gunakan kode ardalis untuk menghemat 20%.
Arsitektur ini digunakan dalam kursus DDD Fundamentals oleh Steve Smith dan Julie Lerman.
? Hubungi perusahaan Steve, Nimblepros, untuk arsitektur bersih atau pelatihan DDD dan/atau bantuan implementasi untuk tim Anda.
Pelajari tentang cara menerapkan arsitektur bersih dari pelatih Nimblepros Sarah "Sadukie" Dutkiewicz dan Steve "Ardalis" Smith.
Jika Anda suka atau menggunakan proyek ini untuk belajar atau memulai solusi Anda, silakan berikan bintang. Terima kasih!
Atau jika Anda merasa sangat murah hati, kami sekarang mendukung sponsor GitHub - lihat tombol di atas.
Saya tolong mengumumkan bahwa dana Foss Amazon AWS telah memilih untuk memberikan sponsor 12 bulan untuk proyek ini. Terima kasih, dan terima kasih untuk semua sponsor masa lalu dan saat ini saya yang lain!
Secara default situs menggunakan HTTPS dan mengharapkan Anda memiliki sertifikat pengembang yang ditandatangani sendiri untuk penggunaan localhost. Jika Anda mendapatkan kesalahan dengan Chrome, lihat jawaban ini untuk instruksi mitigasi.
Cabang utama sekarang menggunakan .NET 9 . Ini sesuai dengan Versi Paket Nuget 10.x. Versi sebelumnya tersedia - lihat rilis kami.
Untuk menggunakan template ini, ada beberapa opsi:
dotnet new (disarankan)Pertama, instal template dari nuget (https://www.nuget.org/packages/ardalis.cleanachitecture.template/):
dotnet new install Ardalis.CleanArchitecture.Template Anda dapat melihat opsi yang tersedia dengan menjalankan perintah dengan -? pilihan:
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 Anda akan melihat template dalam daftar templat dari dotnet new list setelah ini berhasil menginstal. Cari "Asp.net Clean Architecture Solution" dengan nama pendek "Clean-Arch".
Arahkan ke direktori induk tempat Anda ingin folder solusi dibuat.
Jalankan perintah ini untuk membuat struktur solusi dalam nama subfolder Your.ProjectName :
dotnet new clean-arch -o Your.ProjectName
Direktori dan file solusi Your.ProjectName akan dibuat, dan di dalamnya akan menjadi semua konten solusi baru Anda, dengan benar namespaced dan siap untuk dijalankan/diuji!
Contoh: 
Terima kasih @DahlSailRunner atas bantuan Anda agar ini berfungsi!
Masalah yang Diketahui :
Pada versi 9, templat solusi ini hanya mencakup dukungan untuk titik akhir API menggunakan pustaka FastendPoints. Jika Anda ingin menggunakan perpustakaan APIEndPoints saya, halaman pisau cukur, dan/atau pengontrol, Anda dapat menggunakan templat terakhir yang memasukkannya, versi 7.1. Bergantian, mereka mudah ditambahkan ke templat ini setelah instalasi.
Untuk menggunakan Ardalis.ApiendPoints alih -alih (atau di samping) FastendPoints, cukup tambahkan referensi dan gunakan kelas dasar dari dokumentasi.
dotnet add package Ardalis.ApiEndpointsAnda harus menambahkan dukungan untuk pengontrol ke file program.cs. Anda membutuhkan:
builder . Services . AddControllers ( ) ; // ControllersWithView if you need Views
// and
app . MapControllers ( ) ;Setelah ini ada di tempatnya, Anda harus dapat membuat folder pengontrol dan (secara opsional) melihat folder dan semuanya harus berfungsi seperti yang diharapkan. Secara pribadi saya menemukan halaman pisau cukur jauh lebih baik daripada pengontrol dan tampilan jadi jika Anda belum sepenuhnya menyelidiki halaman pisau cukur yang mungkin ingin Anda lakukan sekarang sebelum Anda memilih tampilan.
Anda harus menambahkan dukungan untuk halaman pisau cukur ke file program.cs. Anda membutuhkan:
builder . Services . AddRazorPages ( ) ;
// and
app . MapRazorPages ( ) ;Kemudian Anda cukup menambahkan folder halaman di akar proyek dan pergi dari sana.
Untuk memulai berdasarkan repositori ini, Anda perlu mendapatkan salinan secara lokal. Anda memiliki tiga opsi: garpu, klon, atau unduh. Sebagian besar waktu, Anda mungkin hanya ingin mengunduh.
Anda harus mengunduh repositori , membuka blokir file zip, dan mengekstraknya ke folder baru jika Anda hanya ingin bermain dengan proyek atau Anda ingin menggunakannya sebagai titik awal untuk aplikasi.
Anda harus membayar repositori ini hanya jika Anda berencana mengirimkan permintaan tarik. Atau jika Anda ingin menyimpan salinan snapshot dari repositori di akun GitHub Anda sendiri.
Anda harus mengkloning repositori ini jika Anda salah satu kontributor dan Anda memiliki akses ke sana. Kalau tidak, Anda mungkin menginginkan salah satu opsi lain.
Anda tidak perlu melakukan ini untuk menggunakan templat ini, tetapi jika Anda ingin migrasi diatur dengan benar dalam proyek infrastruktur, Anda perlu menentukan nama proyek itu ketika Anda menjalankan perintah migrasi.
Di Visual Studio, buka Paket Manajer Konsol, dan jalankan Add-Migration InitialMigrationName -StartupProject Your.ProjectName.Web -Context AppDbContext -Project Your.ProjectName.Infrastructure .
Di terminal dengan CLI, perintahnya serupa. Jalankan ini dari direktori proyek web:
dotnet ef migrations add MIGRATIONNAME - c AppDbContext - p .. / Your.ProjectName.Infrastructure / Your.ProjectName.Infrastructure.csproj - s Your.ProjectName.Web.csproj - o Data / Migrations Untuk menggunakan SQLServer, ubah options.UseSqlite(connectionString)); ke options.UseSqlServer(connectionString)); di file Your.ProjectName.Infrastructure.StartupSetup . Juga ingat untuk mengganti SqliteConnection dengan DefaultConnection di file Your.ProjectName.Web.Program , yang menunjuk ke server database Anda.
Untuk memperbarui database, gunakan perintah ini dari folder proyek web (ganti Clean.Architecture dengan nama proyek Anda):
dotnet ef database update - c AppDbContext - p .. / Clean .Architecture.Infrastructure / Clean .Architecture.Infrastructure.csproj - s Clean .Architecture.Web.csprojTujuan dari repositori ini adalah untuk menyediakan struktur solusi dasar yang dapat digunakan untuk membangun desain domain-driven-driven (DDD) yang berbasis atau hanya dengan baik, aplikasi padat menggunakan inti .NET. Pelajari lebih lanjut tentang topik -topik ini di sini:
Jika Anda terbiasa membangun aplikasi sebagai proyek tunggal atau sebagai satu set proyek yang mengikuti ui tradisional -> lapisan bisnis -> lapisan akses data "n -tier" arsitektur, saya sarankan Anda memeriksa dua kursus ini (idealnya sebelum fundamental DDD):
Steve Smith juga memelihara aplikasi referensi Microsoft, EshoponWeb, dan ebook gratis yang terkait. Lihat di sini:
Perhatikan bahwa tujuan proyek dan repositori ini bukan untuk memberikan sampel atau aplikasi referensi. Ini dimaksudkan untuk hanya menjadi templat, tetapi dengan potongan -potongan yang cukup untuk menunjukkan kepada Anda di mana barang -barang berada saat Anda mengatur solusi Anda yang sebenarnya. Alih -alih tidak berguna "class1.cs" ada beberapa kelas nyata di tempatnya. Hapus mereka segera setelah Anda mengerti mengapa mereka ada di sana dan di mana Anda harus meletakkan sendiri file Anda sendiri. Ada aplikasi sampel di folder /sample , jika Anda mencarinya.
Saya telah menggunakan starter kit ini untuk mengajarkan dasar-dasar ASP.NET Core menggunakan konsep dan pola desain yang digerakkan oleh domain untuk beberapa waktu sekarang (mulai ketika ASP.NET Core masih dalam pra-rilis). Biasanya saya mengajar lokakarya langsung satu atau dua hari di depan acara-acara seperti Devintersection, atau lokakarya pribadi di tempat untuk perusahaan yang ingin membawa tim mereka dengan cepat dengan teknologi dan teknik pengembangan terbaru. Jangan ragu untuk menghubungi saya jika Anda ingin informasi tentang lokakarya yang akan datang.
Tujuan dari template solusi ini adalah untuk menyediakan starter kit yang cukup telanjang untuk proyek-proyek baru. Itu tidak termasuk setiap kerangka kerja, alat, atau fitur yang mungkin dimanfaatkan oleh aplikasi perusahaan tertentu. Pilihan teknologi untuk hal -hal seperti akses data berakar pada teknologi yang paling umum dan dapat diakses untuk sebagian besar pengembang perangkat lunak bisnis yang menggunakan tumpukan teknologi Microsoft. Itu tidak (saat ini) memasukkan dukungan luas untuk hal -hal seperti logging, pemantauan, atau analitik, meskipun ini semua dapat ditambahkan dengan mudah. Di bawah ini adalah daftar dependensi teknologi yang termasuk, dan mengapa mereka dipilih. Sebagian besar dari ini dapat dengan mudah ditukar dengan teknologi pilihan Anda, karena sifat arsitektur ini adalah untuk mendukung modularitas dan enkapsulasi.
Validasi input pengguna adalah persyaratan semua aplikasi perangkat lunak. Pertanyaannya adalah, di mana masuk akal untuk mengimplementasikannya dengan cara yang ringkas dan elegan? Template solusi ini mencakup 4 proyek terpisah, yang masing -masing mungkin bertanggung jawab untuk melakukan validasi serta menegakkan invarian bisnis (yang, diberikan validasi yang seharusnya sudah terjadi, biasanya dimodelkan sebagai pengecualian).
Model domain itu sendiri umumnya harus bergantung pada desain yang berorientasi objek untuk memastikannya selalu dalam keadaan yang konsisten. Ini memanfaatkan enkapsulasi dan membatasi akses mutasi negara publik untuk mencapai hal ini, dan diasumsikan bahwa setiap argumen yang disampaikan telah divalidasi, sehingga null atau nilai lain yang tidak patut menghasilkan pengecualian, bukan hasil validasi, dalam kebanyakan kasus.
Proyek Penggunaan Casing / Aplikasi mencakup himpunan semua perintah dan pertanyaan yang didukung sistem. Ini sering bertanggung jawab untuk memvalidasi perintah dan objek permintaannya sendiri. Ini paling mudah dilakukan dengan menggunakan pola rantai tanggung jawab melalui perilaku mediatr atau pipa lainnya.
Proyek Web mencakup semua titik akhir API, yang mencakup jenis permintaan dan respons mereka sendiri, mengikuti pola REP. Perpustakaan FastendPoints mencakup dukungan bawaan untuk validasi menggunakan fluentvalidasi pada jenis permintaan. Ini adalah tempat alami untuk melakukan validasi input juga.
Memiliki validasi terjadi baik dalam titik akhir API dan sekali lagi pada tingkat kasus penggunaan dapat dianggap berlebihan. Ada pengorbanan untuk menambahkan pada dasarnya validasi yang sama di dua tempat, satu untuk permintaan API dan satu lagi untuk pesan yang dikirim untuk menggunakan penangan kasus. Mengikuti pengkodean defensif, seringkali masuk akal untuk menambahkan validasi di kedua tempat, karena overhead minim dan ketenangan pikiran dan ketahanan aplikasi yang lebih besar seringkali sepadan.
Proyek inti adalah pusat desain arsitektur bersih, dan semua dependensi proyek lainnya harus menunjuk ke arahnya. Dengan demikian, ia memiliki sangat sedikit dependensi eksternal. Proyek inti harus mencakup model domain termasuk hal -hal seperti:
Anda dapat mempelajari lebih lanjut tentang pola -pola ini dan cara menerapkannya di sini:
Proyek opsional, saya sudah memasukkannya karena banyak orang menuntutnya dan lebih mudah untuk dihapus daripada menambahkan nanti. Ini juga sering disebut sebagai lapisan aplikasi atau layanan aplikasi . Proyek Kasus Penggunaan diatur mengikuti CQR ke dalam perintah dan kueri (saya mempertimbangkan memiliki folder untuk Commands dan Queries tetapi merasa itu menambahkan sedikit - folder per perintah atau kueri yang sebenarnya cukup tanpa bersarang). Perintah bermutasi model domain dan dengan demikian harus selalu menggunakan abstraksi repositori untuk akses data mereka (repositori adalah bagaimana seseorang mengambil dan bertahan jenis model domain). Kueri hanya dengan baca, dan karenanya tidak perlu menggunakan pola repositori , tetapi sebaliknya dapat menggunakan layanan atau pendekatan kueri apa pun yang paling nyaman.
Karena proyek Kasus Penggunaan diatur untuk bergantung pada inti dan tidak bergantung pada infrastruktur, masih perlu ada abstraksi yang ditentukan untuk akses datanya. Dan itu dapat menggunakan hal -hal seperti spesifikasi, yang kadang -kadang dapat membantu merangkum logika kueri serta pemetaan jenis hasil. Tetapi tidak harus menggunakan repositori/spesifikasi - itu hanya dapat mengeluarkan kueri SQL atau memanggil prosedur tersimpan jika itu cara yang paling efisien untuk mendapatkan data.
Meskipun ini adalah proyek opsional untuk dimasukkan (tanpa itu, titik akhir API Anda hanya akan bekerja secara langsung dengan model domain atau layanan kueri), itu memang menyediakan tempat yang bagus untuk menambahkan tes otomatis, dan cocok untuk menerapkan kebijakan untuk masalah silang menggunakan rantai pola tanggung jawab di sekitar penangan pesan (untuk hal-hal seperti validasi, cacing, auth, auth, auth, auth, auth, auth, auth, auth, latging.) Templat mencakup contoh ini untuk penebangan, yang terletak di paket Sharedkernel Nuget.
Sebagian besar dependensi aplikasi Anda pada sumber daya eksternal harus diimplementasikan di kelas yang ditentukan dalam proyek infrastruktur. Kelas -kelas ini harus mengimplementasikan antarmuka yang didefinisikan dalam inti. Jika Anda memiliki proyek yang sangat besar dengan banyak ketergantungan, mungkin masuk akal untuk memiliki beberapa proyek infrastruktur (misalnya infrastruktur.data), tetapi untuk sebagian besar proyek satu proyek infrastruktur dengan folder berfungsi dengan baik. Templat mencakup akses data dan implementasi acara domain, tetapi Anda juga akan menambahkan hal -hal seperti penyedia email, akses file, klien API Web, dll. Ke proyek ini sehingga mereka tidak menambahkan kopling ke proyek inti atau UI Anda.
Titik masuk aplikasi adalah proyek web Core ASP.NET (atau mungkin proyek Aspirehost, yang pada gilirannya memuat proyek web). Ini sebenarnya adalah aplikasi konsol, dengan metode public static void Main di Program.cs . Ini memanfaatkan titik cepat dan pola rep untuk mengatur titik akhir API -nya.
Kernel bersama digunakan untuk berbagi elemen umum antara konteks terikat. Ini adalah istilah DDD tetapi banyak organisasi memanfaatkan proyek atau paket "umum" untuk hal -hal yang berguna untuk dibagikan antara beberapa aplikasi.
Saya merekomendasikan membuat proyek dan solusi ShareDKernel terpisah jika Anda akan memerlukan kode berbagi antara beberapa konteks terikat (lihat DDD Fundamentals). Lebih lanjut saya merekomendasikan ini diterbitkan sebagai paket Nuget (kemungkinan besar secara pribadi dalam organisasi Anda) dan dirujuk sebagai ketergantungan Nuget oleh proyek -proyek yang memerlukannya.
Sebelumnya proyek untuk ShareDkernel dimasukkan dalam proyek ini. Namun, untuk alasan di atas saya menjadikannya paket terpisah, ardalis.sharedkernel, yang harus Anda ganti dengan Anda saat menggunakan templat ini .
Jika Anda ingin melihat contoh lain dari paket ShareDkernel, yang saya gunakan dalam kursus DDD pluralsight saya yang diperbarui ada di Nuget di sini.
Proyek pengujian dapat diatur berdasarkan jenis tes (unit, fungsional, integrasi, kinerja, dll.) Atau oleh proyek yang mereka uji (inti, infrastruktur, web), atau keduanya. Untuk starter kit sederhana ini, proyek pengujian disusun berdasarkan jenis tes, dengan unit, proyek uji fungsional dan integrasi yang ada dalam solusi ini. Tes fungsional adalah jenis uji integrasi khusus yang melakukan pengujian subkutan dari API proyek Web, tanpa benar -benar menjadi hosting situs web nyata atau melewati jaringan. Saya telah membuat banyak pembantu tes untuk melakukan tes semacam ini lebih pendek dan lebih mudah untuk dirawat.
Template solusi ini memiliki kode yang dibangun untuk mendukung beberapa pola umum, terutama pola desain yang digerakkan oleh domain. Berikut ini adalah gambaran singkat tentang bagaimana beberapa dari mereka bekerja.
Acara domain adalah pola yang bagus untuk memisahkan pemicu untuk operasi dari implementasinya. Ini sangat berguna dari dalam entitas domain karena penangan peristiwa dapat memiliki ketergantungan sementara entitas itu sendiri biasanya tidak. Dalam sampel, Anda dapat melihat ini beraksi dengan metode ToDoItem.MarkComplete() . Diagram urutan berikut menunjukkan bagaimana acara dan pawang digunakan ketika item ditandai lengkap melalui titik akhir API web.
