CleanArchitecture
v10.0.1
Отправная точка для чистой архитектуры с ядром ASP.NET. Чистая архитектура является лишь последней в серии имен для той же слабо связанной, инвертированной зависимостями архитектуры. Вы также найдете это названным шестиугольным, портами и адаптерами или луковой архитектурой.
Узнайте больше о чистой архитектуре и об этом шаблоне в курсе NimblePros 'внедрение чистой архитектуры. Используйте код Ardalis, чтобы сэкономить 20%.
Эта архитектура используется в курсе Fundals DDD Стива Смита и Джули Лерман.
? Свяжитесь с компанией Стива, NimblePros, для чистой архитектуры или обучения DDD и/или помощи в реализации для вашей команды.
Узнайте о том, как внедрить чистую архитектуру от тренеров NimblePros Сары "Садуки" Даткевич и Стив "Ардалис" Смит.
Если вы любите или используете этот проект, чтобы изучить или запустить свое решение, пожалуйста, дайте ему звезду. Спасибо!
Или, если вы чувствуете себя действительно щедрым, мы теперь поддерживаем спонсорство 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 CLEANE ARTHARICTURE Solution» с коротким названием «Чистый арх».
Перейдите к родительскому каталогу, в котором вы хотели бы создать папку решения.
Запустите эту команду, чтобы создать структуру решения в подпапке имени Your.ProjectName :
dotnet new clean-arch -o Your.ProjectName
Будут созданы каталог и файл решения Your.ProjectName , а внутри это будет все ваше новое содержимое решения, правильно с имен и готовые к запуску/тестированию!
Пример: 
Спасибо @dahlsailrunner за вашу помощь, чтобы получить эту работу!
Известные проблемы :
Начиная с версии 9, этот шаблон решения включает в себя поддержку конечных точек API с использованием библиотеки FastendPoints. Если вы хотите использовать мою библиотеку Apiendpoints, страницы бритвы и/или контроллеры, вы можете использовать последний шаблон, который их включал, версия 7.1. Альтернативно, их легко добавить в этот шаблон после установки.
Чтобы использовать ardalis.apiendpoints вместо (или в дополнение к) factendpoints, просто добавьте ссылку и используйте базовые классы из документации.
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.
Вы должны клонировать этот репозиторий , если вы один из участников, и у вас есть доступ к нему. В противном случае вы, вероятно, хотите один из других вариантов.
Вам не нужно делать это, чтобы использовать этот шаблон, но если вы хотите, чтобы миграции были установлены должным образом в проекте инфраструктуры, вам необходимо указать это имя проекта при запуска команды Migrations.
В 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)); to options.UseSqlServer(connectionString)); в файле Your.ProjectName.Infrastructure.StartupSetup . Также не забудьте заменить SqliteConnection на DefaultConnection в файле Your.ProjectName.Web.Program , который указывает на ваш сервер базы данных.
Чтобы обновить базу данных Используйте эту команду из папки веб -проекта (замените Clean.Architecture с помощью имени вашего проекта):
dotnet ef database update - c AppDbContext - p .. / Clean .Architecture.Infrastructure / Clean .Architecture.Infrastructure.csproj - s Clean .Architecture.Web.csprojЦель этого репозитория состоит в том, чтобы обеспечить основную структуру решения, которую можно использовать для создания доменного дизайна (DDD) на основе) или просто хорошо сформированных, твердых приложений с использованием ядра .NET. Узнайте больше об этих темах здесь:
Если вы привыкли создавать приложения в качестве однопроекта или в качестве набора проектов, которые следуют традиционному пользовательскому интерфейсу -> Бизнес -уровне -> Архитектуру доступа к данным «N -Tier», я рекомендую вам проверить эти два курса (в идеале перед основами DDD):
Стив Смит также поддерживает справочное приложение Microsoft, Eshoponweb и связанная с ним бесплатная электронная книга. Проверьте их здесь:
Обратите внимание, что цель этого проекта и репозитория не состоит в том, чтобы предоставить образец или справочное приложение. Это предназначено для того, чтобы быть просто шаблоном, но с достаточным количеством кусочков, чтобы показать вам, где все принадлежит, когда вы настраиваете свое реальное решение. Вместо бесполезного "class1.cs" есть несколько реальных классов. Удалите их, как только вы поймете, почему они там и где вы должны положить свои собственные, похожие файлы. В папке /sample есть применение, если вы ищете это.
Я использовал этот стартовый набор, чтобы научить основы ядра ASP.NET, используя концепции и шаблоны дизайна, управляемые доменом Как правило, я преподаю практический семинар с одним или двухдневным семинаром перед такими мероприятиями, как Devintersection или частные семинары на месте для компаний, стремящихся поднять свои команды с помощью новейших технологий и методов разработки. Не стесняйтесь обращаться ко мне, если вы хотите получить информацию о предстоящих семинарах.
Цель этого шаблона решения состоит в том, чтобы обеспечить довольно начальный набор для новых проектов. Он не включает в себя каждую возможную структуру, инструмент или функцию, которую может выиграть конкретное предприятие. Выбор технологий для таких вещей, как доступ к данным, основан на наиболее распространенной и доступной технологии для большинства разработчиков бизнес -программного обеспечения, использующих технологический стек Microsoft. Он не включает в себя обширную поддержку, таких как ведение журнала, мониторинг или аналитику, хотя все они могут быть легко добавлены. Ниже приведен список технологических зависимостей, которые он включает, и почему они были выбраны. Большинство из них могут быть легко заменены для выбранных вами технологий, поскольку природа этой архитектуры заключается в поддержке модульности и инкапсуляции.
Проверка пользовательского ввода является требованием всех программных приложений. Вопрос в том, где имеет смысл реализовать его кратким и элегантным образом? Этот шаблон решения включает в себя 4 отдельных проекта, каждый из которых может быть ответственен за выполнение проверки, а также для обеспечения соблюдения бизнес -инвариантов (что, учитывая проверку, уже должна была происходить, обычно смоделируются как исключения).
Сама доменная модель, как правило, должна полагаться на объектно-ориентированный дизайн, чтобы убедиться, что она всегда находится в согласованном состоянии. Он использует инкапсуляцию и ограничивает доступ к мутациям государственного государства для достижения этого, и предполагает, что любые переданные ему аргументы уже были подтверждены, поэтому в большинстве случаев нулевые или другие неправильные значения выпускают исключения, а не результаты проверки, в большинстве случаев.
Проект вариантов использования / приложения включает в себя набор всех команд и запросов поддержки системы. Он часто отвечает за проверку собственных объектов команды и запросов. Это наиболее легко делается с использованием цепочки схемы ответственности с помощью поведения в медиатр или какого -либо другого трубопровода.
Веб -проект включает в себя все конечные точки API, которые включают в себя их собственный запрос и типы ответов, следуя шаблону PERP. Библиотека FastendPoints включает в себя встроенную поддержку для проверки с использованием FluentValidation на типах запросов. Это естественное место для выполнения входной проверки.
Наличие валидации происходит как в конечных точках API, так и снова на уровне вариантов использования может считаться избыточным. Существуют компромиссы для добавления практически одинаковой проверки в двух местах, одно для запросов API, а другое для сообщений, отправленных на обработчики использования. После защитного кодирования часто имеет смысл добавлять валидацию в обоих местах, так как накладные расходы минимальны, а душевное спокойствие и большая надежность применения часто того стоит.
Основным проектом является центр дизайна чистой архитектуры, и все другие зависимости проекта должны указывать на него. Таким образом, он имеет очень мало внешних зависимостей. Основной проект должен включать в себя модель домена, включая такие вещи, как:
Вы можете узнать больше об этих моделях и о том, как их применять здесь:
Дополнительный проект, я включил его, потому что многие люди требовали этого, и его легче удалить, чем добавить позже. Это также часто называют слоем приложений или приложений . Проект вариантов использования организован после CQRS в команды и запросы (я подумал о том, чтобы иметь папки для Commands и Queries но чувствовал, что он добавил мало - папки на фактическую команду или запрос достаточно без дополнительного гнездования). Команды мутируют модель домена и, следовательно, должны всегда использовать абстракции репозитория для их доступа к данным (репозитории - это то, как кто -то извлекает и сохраняет типы доменных моделей). Запросы читаются, и, следовательно, не нужно использовать шаблон репозитория , но вместо этого могут использовать любую службу запросов или подход, что является наиболее удобным.
Поскольку проект вариантов использования настроен на зависимость от ядра и не зависит от инфраструктуры, все равно потребуется абстракции, определенные для его доступа к данным. И он может использовать такие вещи, как спецификации, которые иногда могут помочь инкапсулировать логику запросов, а также отображение типа результата. Но он не должен использовать репозиторий/спецификацию - он может просто задать запрос SQL или вызвать хранимую процедуру, если это наиболее эффективный способ получить данные.
Хотя это дополнительный проект для включения (без него, ваши конечные точки API будут просто работать непосредственно с доменной моделью или службами запросов), он обеспечивает хорошее место для U-ignorant для добавления автоматических тестов и поддается применению политики для перекрестных проблем, используя цепочку ответственности вокруг обработчиков сообщений (для таких вещей, как валидация, caching, worging, timing, trinting или upting или irpling или irpling. Шаблон включает в себя пример этого для регистрации, который расположен в пакете Sharedkernel Nuget.
Большая часть зависимости вашего приложения от внешних ресурсов должна быть реализована в классах, определенных в инфраструктурном проекте. Эти классы должны реализовать интерфейсы, определенные в ядре. Если у вас есть очень большой проект со многими зависимостями, может иметь смысл иметь несколько инфраструктурных проектов (например, инфраструктура.data), но для большинства проектов один проект инфраструктуры с папками работает нормально. Шаблон включает в себя доступ к данным и реализации событий домена, но вы также добавите такие вещи, как поставщики электронной почты, доступ к файлам, клиенты Web API и т. Д. В этот проект, чтобы они не добавляли связь с вашим основным или пользовательским проектом.
Точкой входа приложения является основной веб -проект ASP.NET (или, возможно, проект AspireHost, который, в свою очередь, загружает веб -проект). Это на самом деле консольное приложение с public static void Main в Program.cs . CS. Он использует точки FASTEND и образец PERP, чтобы организовать свои конечные точки API.
Общее ядро используется для обмена общими элементами между ограниченными контекстами. Это термин DDD, но многие организации используют «общие» проекты или пакеты для вещей, которые полезны для разделения между несколькими приложениями.
Я рекомендую создать отдельный проект Sharedkernel и решение, если вам потребуется код обмена между несколькими ограниченными контекстами (см. Основы DDD). Я также рекомендую, чтобы это было опубликовано как пакет Nuget (скорее всего, в частной собственности в вашей организации) и ссылается на зависимость Nuget в тех проектах, которые требуют этого.
Ранее в этот проект был включен проект Sharedkernel. Однако по приведенным выше причинам я сделал его отдельным пакетом, Ardalis.sharedkernel, который вы должны заменить своим собственным при использовании этого шаблона .
Если вы хотите увидеть еще один пример пакета ShareDkernel, который я использую в своем курсе DDD с обновленным множественным планом, находится здесь на Nuget.
Тестовые проекты могут быть организованы на основе вида теста (единица, функционала, интеграции, производительности и т. Д.) Или по проекту, который они тестируют (Core, Infrastructure, Web) или оба. Для этого простого стартового комплекта проекты тестирования организованы на основе вида теста, с единичными, функциональными и интеграционными тестами, существующими в этом решении. Функциональные тесты представляют собой особый вид интеграционного теста, который выполняет подкожную тестирование API -интерфейсов веб -проекта, без фактического размещения реального веб -сайта и не проходя через сеть. Я создал кучу тестовых помощников, чтобы сделать такие тесты короче и легче поддерживать.
Этот шаблон решения имеет встроенный код, чтобы поддержать несколько общих шаблонов, особенно дизайнерских шаблонов, управляемых доменом. Вот краткий обзор того, как некоторые из них работают.
События домена являются отличным шаблоном для отделения триггера для операции из ее реализации. Это особенно полезно из доменных сущностей, поскольку обработчики событий могут иметь зависимости, в то время как сами сущности обычно этого не делают. В примере вы можете увидеть это в действии с помощью метода ToDoItem.MarkComplete() . Следующая диаграмма последовательности демонстрирует, как событие и его обработчик используются, когда элемент помещен в конечную точку веб -API.
