CleanArchitecture
v10.0.1
จุดเริ่มต้นสำหรับสถาปัตยกรรมที่สะอาดด้วย ASP.NET CORE Clean Architecture เป็นเพียงชื่อล่าสุดในชุดของชื่อสำหรับสถาปัตยกรรมที่พึ่งพาอาศัยกันอย่างหลวม ๆ นอกจากนี้คุณยังจะพบว่ามันมีชื่อว่า Hexagonal, Ports-and-Adapters หรือ Onion Architecture
เรียนรู้เพิ่มเติมเกี่ยวกับสถาปัตยกรรมที่สะอาดและเทมเพลตนี้ในหลักสูตรสถาปัตยกรรมที่สะอาดของ NimblePros ใช้รหัส Ardalis เพื่อประหยัด 20%
สถาปัตยกรรมนี้ใช้ในหลักสูตรพื้นฐาน DDD โดย Steve Smith และ Julie Lerman
- ติดต่อ บริษัท ของ Steve, Nimblepros สำหรับสถาปัตยกรรมที่สะอาดหรือการฝึกอบรม DDD และ/หรือความช่วยเหลือในการนำไปปฏิบัติสำหรับทีมของคุณ
เรียนรู้เกี่ยวกับวิธีการใช้สถาปัตยกรรมที่สะอาดจากผู้ฝึกสอน Nimblepros Sarah "Sadukie" Dutkiewicz และ Steve "Ardalis" Smith
หากคุณชอบหรือใช้โครงการนี้เพื่อเรียนรู้หรือเริ่มต้นการแก้ปัญหาของคุณโปรดให้ดาว ขอบคุณ!
หรือถ้าคุณรู้สึกใจกว้างจริงๆตอนนี้เราสนับสนุนการสนับสนุนของ GitHub - ดูปุ่มด้านบน
ฉันโปรดประกาศว่า Foss Fund ของ Amazon AWS ได้เลือกที่จะมอบรางวัลสปอนเซอร์ 12 เดือนให้กับโครงการนี้ ขอบคุณและขอบคุณผู้สนับสนุนอดีตและปัจจุบันของฉันทั้งหมด!
โดยค่าเริ่มต้นเว็บไซต์จะใช้ HTTPS และคาดว่าคุณจะมีใบรับรองนักพัฒนาที่ลงชื่อด้วยตนเองสำหรับการใช้งาน LocalHost หากคุณได้รับข้อผิดพลาดกับ Chrome ให้ดูคำตอบนี้สำหรับคำแนะนำในการบรรเทาผลกระทบ
สาขาหลักกำลังใช้ . NET 9 สิ่งนี้สอดคล้องกับ Nuget Package เวอร์ชัน 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 หลังจากการติดตั้งนี้สำเร็จ มองหา "ASP.NET Clean Architecture Solution" ด้วยชื่อสั้น ๆ ของ "Clean-ARCH"
นำทางไปยังไดเรกทอรีหลักที่คุณต้องการสร้างโฟลเดอร์โซลูชัน
เรียกใช้คำสั่งนี้เพื่อสร้างโครงสร้างโซลูชันในชื่อโฟลเดอร์ย่อย Your.ProjectName :
dotnet new clean-arch -o Your.ProjectName
ไดเรกทอรีและไฟล์โซลูชัน Your.ProjectName จะถูกสร้างขึ้นและภายในซึ่งจะเป็นเนื้อหาโซลูชันใหม่ทั้งหมดของคุณได้อย่างเหมาะสมและพร้อมที่จะเรียกใช้/ทดสอบ!
ตัวอย่าง: 
ขอบคุณ @dahlsailrunner สำหรับความช่วยเหลือของคุณในการทำงานนี้!
ปัญหาที่รู้จัก :
ในฐานะที่เป็นเวอร์ชัน 9 เทมเพลตโซลูชันนี้มีเพียงการรองรับจุดสิ้นสุด API โดยใช้ไลบรารี FastEndpoints หากคุณต้องการใช้ไลบรารี ApiendPoints ของฉันหน้ามีดโกนและ/หรือคอนโทรลเลอร์คุณสามารถใช้เทมเพลตล่าสุดที่รวมเวอร์ชัน 7.1 อีกวิธีหนึ่งพวกมันจะเพิ่มไปยังเทมเพลตนี้ได้อย่างง่ายดายหลังจากการติดตั้ง
หากต้องการใช้ Ardalis.apiendpoints แทน (หรือนอกเหนือจาก) Fastendpoints เพียงเพิ่มการอ้างอิงและใช้คลาสพื้นฐานจากเอกสาร
dotnet add package Ardalis.ApiEndpointsคุณจะต้องเพิ่มการสนับสนุนสำหรับคอนโทรลเลอร์ลงในไฟล์ program.cs คุณต้องการ:
builder . Services . AddControllers ( ) ; // ControllersWithView if you need Views
// and
app . MapControllers ( ) ;เมื่อสิ่งเหล่านี้อยู่ในสถานที่คุณควรจะสามารถสร้างโฟลเดอร์คอนโทรลเลอร์และโฟลเดอร์มุมมอง (ทางเลือก) และทุกอย่างควรทำงานตามที่คาดไว้ โดยส่วนตัวแล้วฉันพบว่าหน้ามีดโกนดีกว่าคอนโทรลเลอร์และมุมมองมากดังนั้นหากคุณยังไม่ได้ตรวจสอบหน้ามีดโกนอย่างสมบูรณ์คุณอาจต้องการทำเช่นนั้นก่อนที่คุณจะเลือกมุมมอง
คุณจะต้องเพิ่มการสนับสนุนสำหรับหน้ามีดโกนลงในไฟล์ program.cs คุณต้องการ:
builder . Services . AddRazorPages ( ) ;
// and
app . MapRazorPages ( ) ;จากนั้นคุณเพียงแค่เพิ่มโฟลเดอร์หน้าในรูทของโครงการและไปจากที่นั่น
ในการเริ่มต้นตามที่เก็บนี้คุณจะต้องได้รับสำเนาในพื้นที่ คุณมีสามตัวเลือก: ส้อมโคลนหรือดาวน์โหลด ส่วนใหญ่คุณอาจต้องการดาวน์โหลด
คุณควร ดาวน์โหลดที่เก็บปลด บล็อกไฟล์ zip และแยกออกไปยังโฟลเดอร์ใหม่หากคุณต้องการเล่นกับโครงการหรือคุณต้องการใช้เป็นจุดเริ่มต้นสำหรับแอปพลิเคชัน
คุณควร แยกที่เก็บนี้ เฉพาะในกรณีที่คุณวางแผนที่จะส่งคำขอดึง หรือหากคุณต้องการเก็บสำเนาสแนปชอตของที่เก็บในบัญชี GitHub ของคุณเอง
คุณควร โคลนพื้นที่เก็บข้อมูลนี้ หากคุณเป็นหนึ่งในผู้มีส่วนร่วมและคุณมีความมุ่งมั่นในการเข้าถึง มิฉะนั้นคุณอาจต้องการหนึ่งในตัวเลือกอื่น ๆ
คุณไม่จำเป็นต้องทำเช่นนี้เพื่อใช้เทมเพลตนี้ แต่ถ้าคุณต้องการการย้ายถิ่นฐานการตั้งค่าอย่างถูกต้องในโครงการโครงสร้างพื้นฐานคุณต้องระบุชื่อโครงการนั้นเมื่อคุณเรียกใช้คำสั่งการย้ายถิ่น
ใน Visual Studio ให้เปิดคอนโซล Package Manager และเรียกใช้ Add-Migration InitialMigrationName -StartupProject Your.ProjectName.Web -Context AppDbContext -Project Your.ProjectName.Infrastructure . 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 . projectName.InfraStructure.startupSetup อย่าลืมแทนที่การเปลี่ยน SqliteConnection ด้วย DefaultConnection ในไฟล์ Your.ProjectName.Web.Program ซึ่งชี้ไปที่เซิร์ฟเวอร์ฐานข้อมูลของคุณ
ในการอัปเดตฐานข้อมูลให้ใช้คำสั่งนี้จากโฟลเดอร์ Web Project (แทนที่ Clean.Architecture ด้วยชื่อโครงการของคุณ):
dotnet ef database update - c AppDbContext - p .. / Clean .Architecture.Infrastructure / Clean .Architecture.Infrastructure.csproj - s Clean .Architecture.Web.csprojเป้าหมายของพื้นที่เก็บข้อมูลนี้คือการจัดทำโครงสร้างโซลูชันพื้นฐานที่สามารถใช้ในการสร้างการออกแบบที่ขับเคลื่อนด้วยโดเมน (DDD) ที่ใช้หรือเพียงแค่มีการประยุกต์ใช้งานที่ดีโดยใช้. NET Core เรียนรู้เพิ่มเติมเกี่ยวกับหัวข้อเหล่านี้ที่นี่:
หากคุณคุ้นเคยกับการสร้างแอปพลิเคชันเป็นโครงการเดียวหรือเป็นชุดของโครงการที่เป็นไปตามสถาปัตยกรรม UI แบบดั้งเดิม -> ชั้นธุรกิจ -> สถาปัตยกรรมการเข้าถึงข้อมูล "N -Tier" ฉันขอแนะนำให้คุณตรวจสอบหลักสูตรสองหลักสูตรนี้ (ก่อนพื้นฐาน DDD):
Steve Smith ยังคงรักษาแอพพลิเคชั่นอ้างอิงของ Microsoft, EshoponWeb และ ebook ฟรีที่เกี่ยวข้อง ตรวจสอบพวกเขาที่นี่:
โปรดทราบว่าเป้าหมายของโครงการและที่เก็บนี้ ไม่ ได้ให้ตัวอย่างหรือแอปพลิเคชันอ้างอิง มันหมายถึงการเป็นเทมเพลต แต่มีชิ้นส่วนเพียงพอที่จะแสดงให้คุณเห็นว่าสิ่งต่าง ๆ อยู่ในขณะที่คุณตั้งค่าโซลูชันจริงของคุณ แทนที่จะเป็น "class1.cs" ที่ไร้ประโยชน์มีคลาสจริงสองสามชั้น ลบพวกเขาทันทีที่คุณเข้าใจว่าทำไมพวกเขาถึงอยู่ที่นั่นและสถานที่ที่คุณควรใส่ไฟล์ที่คล้ายกันของคุณเอง มี แอปพลิเคชันตัวอย่างในโฟลเดอร์ /sample หากคุณกำลังมองหาสิ่งนั้น
ฉันใช้ชุดเริ่มต้นนี้เพื่อสอนพื้นฐานของ ASP.NET Core โดยใช้แนวคิดและรูปแบบการออกแบบที่ขับเคลื่อนด้วยโดเมนมาระยะหนึ่งแล้ว (เริ่มต้นเมื่อ ASP.NET Core ยังอยู่ในการวางจำหน่ายก่อน) โดยทั่วไปแล้วฉันสอนการประชุมเชิงปฏิบัติการแบบหนึ่งหรือสองวันก่อนเหตุการณ์เช่น DEVINTERSECTION หรือเวิร์กช็อปในสถานที่ส่วนตัวสำหรับ บริษัท ที่ต้องการนำทีมของพวกเขาเร่งความเร็วด้วยเทคโนโลยีและเทคนิคการพัฒนาล่าสุด อย่าลังเลที่จะติดต่อฉันหากคุณต้องการข้อมูลเกี่ยวกับการประชุมเชิงปฏิบัติการที่กำลังจะมาถึง
เป้าหมายของเทมเพลตโซลูชันนี้คือการจัดเตรียมชุดเริ่มต้นที่ค่อนข้างเปลือยเปล่าสำหรับโครงการใหม่ ไม่รวมถึงกรอบเครื่องมือหรือคุณลักษณะที่เป็นไปได้ทุกอย่างที่แอปพลิเคชันองค์กรเฉพาะอาจได้รับประโยชน์จาก ตัวเลือกของเทคโนโลยีสำหรับสิ่งต่าง ๆ เช่นการเข้าถึงข้อมูลมีรากฐานมาจากเทคโนโลยีที่พบได้บ่อยที่สุดสำหรับนักพัฒนาซอฟต์แวร์ธุรกิจส่วนใหญ่โดยใช้สแต็กเทคโนโลยีของ Microsoft มันไม่ได้ (ปัจจุบัน) รวมถึงการสนับสนุนอย่างกว้างขวางสำหรับสิ่งต่าง ๆ เช่นการบันทึกการตรวจสอบหรือการวิเคราะห์แม้ว่าสิ่งเหล่านี้สามารถเพิ่มได้อย่างง่ายดาย ด้านล่างนี้เป็นรายการของการพึ่งพาเทคโนโลยีที่มีและทำไมพวกเขาจึงถูกเลือก สิ่งเหล่านี้ส่วนใหญ่สามารถเปลี่ยนได้อย่างง่ายดายสำหรับเทคโนโลยีที่คุณเลือกเนื่องจากธรรมชาติของสถาปัตยกรรมนี้คือการสนับสนุนโมดูลาร์และการห่อหุ้ม
การตรวจสอบความถูกต้องของการป้อนข้อมูลผู้ใช้เป็นข้อกำหนดของแอพพลิเคชั่นซอฟต์แวร์ทั้งหมด คำถามคือมันเหมาะสมที่จะนำไปใช้ในลักษณะที่กระชับและสง่างาม? เทมเพลตโซลูชันนี้มี 4 โครงการแยกกันซึ่งแต่ละโครงการอาจรับผิดชอบในการตรวจสอบความถูกต้องรวมถึงการบังคับใช้ค่าคงที่ทางธุรกิจ (ซึ่งควรมีการตรวจสอบความถูกต้องแล้วมักจะเป็นแบบจำลองเป็นข้อยกเว้น)
แบบจำลองโดเมนโดยทั่วไปควรพึ่งพาการออกแบบเชิงวัตถุเพื่อให้แน่ใจว่าอยู่ในสถานะที่สอดคล้องกันเสมอ มันใช้ประโยชน์จากการห่อหุ้มและ จำกัด การเข้าถึงการกลายพันธุ์ของรัฐเพื่อให้บรรลุเป้าหมายนี้และสันนิษฐานว่าอาร์กิวเมนต์ใด ๆ ที่ส่งผ่านไปยังได้รับการตรวจสอบแล้วดังนั้นค่า NULL หรือค่าที่ไม่เหมาะสมอื่น ๆ จะให้ข้อยกเว้นไม่ใช่ผลการตรวจสอบในกรณีส่วนใหญ่
โครงการกรณีการใช้งาน / แอปพลิเคชันรวมชุดของคำสั่งทั้งหมดและการสืบค้นที่ระบบรองรับ มันมักจะรับผิดชอบในการตรวจสอบความถูกต้องของคำสั่งและการสืบค้นวัตถุ สิ่งนี้ทำได้ง่ายที่สุดโดยใช้รูปแบบความรับผิดชอบผ่านพฤติกรรม MediaTR หรือท่ออื่น ๆ
โครงการเว็บรวมถึงจุดสิ้นสุด API ทั้งหมดซึ่งรวมถึงคำขอและประเภทการตอบสนองของตนเองตามรูปแบบ repr ไลบรารี FastEndpoints รวมถึงการสนับสนุนในตัวสำหรับการตรวจสอบความถูกต้องโดยใช้ FluentValidation ในประเภทคำขอ นี่เป็นสถานที่ธรรมชาติในการตรวจสอบความถูกต้องของอินพุตเช่นกัน
การมีการตรวจสอบเกิดขึ้นทั้งภายในจุดสิ้นสุด API และจากนั้นอีกครั้งที่ระดับกรณีการใช้งานอาจได้รับการพิจารณาซ้ำซ้อน มีการแลกเปลี่ยนเพื่อเพิ่มการตรวจสอบความถูกต้องเดียวกันในสองแห่งหนึ่งแห่งสำหรับคำขอ API และอีกรายการสำหรับข้อความที่ส่งไปยังตัวจัดการเคส หลังจากการเข้ารหัสการป้องกันมันมักจะเหมาะสมที่จะเพิ่มการตรวจสอบความถูกต้องในทั้งสองสถานที่เนื่องจากค่าใช้จ่ายน้อยที่สุดและความสงบของจิตใจและความทนทานต่อการใช้งานที่มากขึ้นมักจะคุ้มค่า
โครงการหลักคือศูนย์กลางของการออกแบบสถาปัตยกรรมที่สะอาดและการพึ่งพาโครงการอื่น ๆ ทั้งหมดควรชี้ไปที่มัน ดังนั้นจึงมีการพึ่งพาภายนอกน้อยมาก โครงการหลักควรรวมโมเดลโดเมนรวมถึงสิ่งต่าง ๆ เช่น:
คุณสามารถเรียนรู้เพิ่มเติมเกี่ยวกับรูปแบบเหล่านี้และวิธีการใช้ที่นี่:
โครงการเสริมฉันได้รวมไว้เพราะคนจำนวนมากเรียกร้องและมันง่ายกว่าที่จะลบมากกว่าที่จะเพิ่มในภายหลัง สิ่งนี้มักจะเรียกว่า เลเยอร์แอปพลิเคชัน หรือ แอปพลิเคชัน โครงการใช้กรณีการใช้งานถูกจัดระเบียบตาม CQRS เป็นคำสั่งและการสืบค้น (ฉันพิจารณาว่ามีโฟลเดอร์สำหรับ Commands และ Queries แต่รู้สึกว่ามันเพิ่มน้อย - โฟลเดอร์ต่อ คำสั่ง จริงหรือ แบบสอบถาม เพียงพอโดยไม่ต้องทำรังเพิ่มเติม) คำสั่งกลายพันธุ์โมเดลโดเมนและควรใช้ abstractions ที่เก็บสำหรับการเข้าถึงข้อมูลของพวกเขาเสมอ แบบสอบถามเป็นแบบอ่านอย่างเดียวและ ไม่จำเป็นต้องใช้รูปแบบที่เก็บ แต่สามารถใช้บริการแบบสอบถามหรือวิธีการใดก็ได้ที่สะดวกที่สุด
เนื่องจากโครงการใช้กรณีการใช้งานได้รับการตั้งค่าให้ขึ้นอยู่กับแกนกลางและไม่ได้ขึ้นอยู่กับโครงสร้างพื้นฐานจึงยังคงต้องเป็นนามธรรมที่กำหนดไว้สำหรับการเข้าถึงข้อมูล และ สามารถ ใช้สิ่งต่าง ๆ เช่นข้อกำหนดซึ่งบางครั้งอาจช่วยห่อหุ้มตรรกะการสืบค้นรวมถึงการแมปประเภทผลลัพธ์ แต่ไม่ จำเป็น ต้องใช้ที่เก็บ/ข้อกำหนด - มันสามารถออกคำสั่ง SQL หรือเรียกขั้นตอนที่เก็บไว้ได้หากเป็นวิธีที่มีประสิทธิภาพที่สุดในการรับข้อมูล
แม้ว่านี่จะเป็นโครงการเสริมที่จะรวม (หากไม่มีมันจุดสิ้นสุด API ของคุณจะทำงานโดยตรงกับโมเดลโดเมนหรือบริการสอบถาม) แต่ก็เป็นสถานที่ที่ดีในการเพิ่มการทดสอบอัตโนมัติและให้ยืมตัวเองไปใช้นโยบายสำหรับการตัดข้าม เทมเพลตประกอบด้วยตัวอย่างของสิ่งนี้สำหรับการบันทึกซึ่งอยู่ในแพ็คเกจ SharedKernel NuGet
การพึ่งพาทรัพยากรภายนอกของแอปพลิเคชันส่วนใหญ่ของคุณควรดำเนินการในชั้นเรียนที่กำหนดไว้ในโครงการโครงสร้างพื้นฐาน คลาสเหล่านี้ควรใช้อินเทอร์เฟซที่กำหนดไว้ใน Core หากคุณมีโครงการที่มีขนาดใหญ่มากที่มีการพึ่งพาจำนวนมากมันอาจเหมาะสมที่จะมีโครงการโครงสร้างพื้นฐานหลายโครงการ (เช่นโครงสร้างพื้นฐาน. data) แต่สำหรับโครงการส่วนใหญ่โครงการโครงสร้างพื้นฐานหนึ่งโครงการที่มีโฟลเดอร์ทำงานได้ดี เทมเพลตรวมถึงการใช้งานข้อมูลและการใช้งานโดเมน แต่คุณจะเพิ่มสิ่งต่าง ๆ เช่นผู้ให้บริการอีเมลการเข้าถึงไฟล์ไคลเอนต์ Web API ฯลฯ ในโครงการนี้ดังนั้นพวกเขาจึงไม่ได้เพิ่มการเชื่อมต่อในโครงการ Core หรือ UI ของคุณ
จุดเริ่มต้นของแอปพลิเคชันคือโครงการเว็บหลักของ ASP.NET (หรืออาจเป็นโครงการ Aspirehost ซึ่งจะโหลดโครงการเว็บ) นี่คือแอปพลิเคชั่นคอนโซลที่มีวิธี public static void Main ใน Program.cs มันใช้ประโยชน์จาก FastEndpoints และรูปแบบ repr เพื่อจัดระเบียบจุดสิ้นสุด API
เคอร์เนลที่ใช้ร่วมกันใช้เพื่อแบ่งปันองค์ประกอบทั่วไประหว่างบริบทที่มีขอบเขต มันเป็นคำศัพท์ DDD แต่หลายองค์กรใช้ประโยชน์จากโครงการหรือแพ็คเกจทั่วไปสำหรับสิ่งต่าง ๆ ที่มีประโยชน์ในการแบ่งปันระหว่างแอปพลิเคชันหลายรายการ
ฉันขอแนะนำให้สร้างโครงการ SharedKernel แยกต่างหากและโซลูชันหากคุณต้องการรหัสการแบ่งปันระหว่างบริบทที่มีขอบเขตหลายอย่าง (ดูพื้นฐาน DDD) ฉันขอแนะนำเพิ่มเติมว่าสิ่งนี้จะเผยแพร่เป็นแพ็คเกจ NUGET (ส่วนใหญ่เป็นส่วนตัวภายในองค์กรของคุณ) และอ้างอิงว่าเป็นการพึ่งพา NUGET โดยโครงการเหล่านั้นที่ต้องการ
ก่อนหน้านี้โครงการสำหรับ SharedKernel รวมอยู่ในโครงการนี้ อย่างไรก็ตามด้วยเหตุผลข้างต้นฉันทำให้มันเป็นแพ็คเกจแยกต่างหาก Ardalis.sharedkernel ซึ่ง คุณควรแทนที่ด้วยตัวเองเมื่อคุณใช้เทมเพลตนี้
หากคุณต้องการดูตัวอย่างอื่นของแพ็คเกจ SharedKernel อันที่ฉันใช้ในหลักสูตร Pluralsight DDD ที่อัปเดตของฉันอยู่ที่ Nuget ที่นี่
โครงการทดสอบสามารถจัดระเบียบได้ตามประเภทของการทดสอบ (หน่วยการทำงานการรวมประสิทธิภาพ ฯลฯ ) หรือโดยโครงการที่พวกเขากำลังทดสอบ (หลัก, โครงสร้างพื้นฐาน, เว็บ) หรือทั้งสองอย่าง สำหรับชุดเริ่มต้นอย่างง่ายนี้โครงการทดสอบจะถูกจัดระเบียบตามประเภทของการทดสอบด้วยหน่วยการทดสอบการทำงานและการทดสอบการรวมที่มีอยู่ในโซลูชันนี้ การทดสอบการใช้งานเป็นการทดสอบการรวมแบบพิเศษที่ทำการทดสอบใต้ผิวหนังของ APIs ของโครงการเว็บโดยไม่ต้องโฮสต์เว็บไซต์จริงหรือข้ามเครือข่าย ฉันได้สร้างผู้ช่วยทดสอบจำนวนมากเพื่อทำการทดสอบประเภทนี้ให้สั้นลงและง่ายต่อการบำรุงรักษา
เทมเพลตโซลูชันนี้มีรหัสในตัวเพื่อรองรับรูปแบบทั่วไปบางอย่างโดยเฉพาะอย่างยิ่งรูปแบบการออกแบบที่ขับเคลื่อนด้วยโดเมน นี่คือภาพรวมโดยย่อของวิธีการทำงานของพวกเขา
เหตุการณ์โดเมนเป็นรูปแบบที่ยอดเยี่ยมสำหรับการแยกทริกเกอร์สำหรับการดำเนินการจากการดำเนินการ สิ่งนี้มีประโยชน์อย่างยิ่งจากภายในเอนทิตีของโดเมนเนื่องจากตัวจัดการของเหตุการณ์สามารถมีการพึ่งพาในขณะที่หน่วยงานของตัวเองมักจะไม่ทำ ในตัวอย่างคุณสามารถเห็นสิ่งนี้ได้ด้วยวิธีการ ToDoItem.MarkComplete() แผนภาพลำดับต่อไปนี้แสดงให้เห็นว่าเหตุการณ์และตัวจัดการถูกใช้เมื่อรายการถูกทำเครื่องหมายเสร็จสมบูรณ์ผ่านจุดสิ้นสุดของเว็บ API
