Описание и предназначение

Шаблон Nimble Framework позволяет максимально быстро развернуть новое решение (solution), в котором будут настроены проекты (projects) и подключено (установлено) всё то, что требуется для старта процесса разработки, чтобы приступить непосредственно к решению поставленной задачи. Другими словами, позволяет упростить создание микросервиса (backend-сервера для SPA) на базе ASP.NET Core, которые готовы к дальнейшему расширению или какому-либо другому преобразованию, например, установка дополнительных nuget-пакетов. Когда микросервисы объединены в одну систему (МСА), они не могут быть не связаны между собой. Для облегчения этой задачи "введение нового сервиса в систему" также и предназначен шаблон, в который заложены базовые инфраструктурные функции и возможности.

В проектах, созданные из шаблона используется Coding Convention описанный компанией Microsoft, потому как определяет основные правила именования методов, переменных, полей, функций. А также Identifier names | Microsoft Docs для именование идентификаторов от той же самой компании Microsoft. Все проекты шаблонов построены на платформе разных версий .NET

Подходы к написанию кода

Стоит отметить, что основной функционал заложенный в шаблон (способы описанные ниже) легко вернуть к исходному (чистый ASP.NET Core MVC) из сгенерированного проекта простым удалением двух сборок из списка nuget-пакектов и пару папок. Таким образом, превратив проект в "голый", но при этом содержащий все заложенные в него инфраструктурные механизмы: логирование, мониторинг, подключение к системе, регистрация в AuthorizationService и т.д.  

Способ "Быстрый"

Следуя из названия способа напрашивается вывод, что можно разрабатывать API сервиса очень быстро, и, на самом деле, так оно и сесть. Разработка методов CRUD получается очень быстрой. Такой подход используется для простых (или относительно простых сущностей).  Пример использования "скоростного" подхода с детальным описанием и подробными комментариями.

Пример использования

Требуется быстро "поднять" сервис, который будет иметь одну сущность, например, "DocumentType" для использования как справочник (то есть, только для чтения по идентификатору и получение постраничного списка). Вторая сущность "Message", для которой требуется элементарный CRUD без каких-либо излишество в бизнес-логики. Создание контроллеров DocumentTypeController и MessagesController на базе уже реализованных ReadonlyControllerBase и WritableControllerBase займет не более получаса при использовании данного способа.

Способ "Правильный" 

Способ, который должен браться за основу. Реализация функционала построена на базе Mediatr (близко к паттерну CQRS), что позволяет реализовать Vertical Slice Architecture (VSA). Использование VSA позволяет гибко и эффективно использовать подход разделяющий такие понятия как Query и Command, тем самым дает возможность масштабировать возможности "вертикально".

Преимущества большие, потому что вы сможете использовать обработчики Query и Command (паттерн CQRS) обрабатывать удобным (правильным, подходящим, эффективным, выбранным на основании условия, в конце-концов) способом для достижения максимального результата. Более того, такое понятие pipeline, заложенное в VSA, дает очень гибкой настройки процесса обработки запросов. Следовательно, вы можете "вклеить" специализированные обработчики, например, логирование, кэширование, обработку транзакций и прочите необходимые "полезности" на уровне базовых реализаций - на уровне шаблона. 

На рисунке ниже, все методы работают по одному принципу, но сами обработчики разные, причем в некоторых вариантах диаметрально противоположные. От ORM до StoredProcedure при необходимости. Даже не смотря на то, что StoredProcedure - это шаг к двухзвенной архитектуре (а это 100 шагов назад в истории разработки).

Подсказка

Заметьте, что всегда можно удалить одну сборку, которая реализует способ "Быстрый" и установить другую, которая реализует способ "Правильный", чтобы расширить возможности реализации бизнес-логики. Более того, можно использовать обе сборки параллельно.

Для чего шаблон?

Основа для старта

Шаблон создается как отправная точка для разработки нового микросервиса (backend или API), в котором заложены основы некоторых механизмов и подходов с примерами их использования в том числе. Использование шаблона универсализирует эти самые механизмы и подходы при использовании в разных микросервисах, созданных на базе одного и того же шаблона. Разработчику проще ориентироваться в "знакомом" проекте, например, использовать один и тот же способ делать запросы к базе данных, в также дорабатывать расширения для шаблона, делиться ими с другими разработчиками в других проектах (в контексте командной разработки).

Универсальность

Попробуем выделить основные аспекты, которые позволяет решить или существенно упростить использование шаблона:

1. Шаблон включает нужные для всех микросервисов сборки и пакеты. Нужные новые - поставь, не нужные какие-то - удали. Часто добавляешь? Добавь в шаблон и т.д.;
2. Шаблон включает (или может включать) общие (базовые) настройки на стандартных механизмов:
   1. Настройки подключения к MassTransit (через RabbitMQ);
   2. Настройки подключения к ELK для логирования;
   3. Настройки .editorconfig для среды разработки;
   4. Настройки CI/DC;
   5. Настройка подключения к Database;
3. Шаблон включает общий (базовый) функционал:
   1. Расширения (extensions) для примитивных типов в C# (например, IsEmpty());
   2. Демонстрационные примеры использования тех или иных механизмов (изучив которые, можно просто удалить);
   3. Мониторинг на основе принятых в компании договоренностей;
   4. Работу с сервером аутентификации и авторизации OAuth2.0;
   5. Обеспечение защиты методов на базе встроенного в ASP.NET Core механизма авторизации и аутентификации (например, атрибут Authorize) настроенного на сервер авторизации;
4. Универсальную структуру проектов в компании, которая поможет проще "входить" разработчикам в проект, и более осознано ориентироваться в проекте, построенных на базе одного или нескольких шаблонов.

Развитие

Существует два варианта дальнейшего развития использования шаблонов для разного типа проектов.

• Расширять возможности одного шаблона через сборки (nuget-пакеты).

Принцип 1

Cоздал новый микросервис из одного общего шаблона, установил nuget-пакеты те, которые тебе нужны, чтобы реализовать бизнес-логику. Например, потребовался доступ к шине сообщений - уставил какой надо nuget-пакет.

• Увеличивать количество шаблонов с реализацией конкретных возможностей.

Принцип 2

Cоздал проект из конкретного типа шаблона. Например, потребовался доступ к шине сообщений - взял за основу TemplateWithRabbitMQ.

Общая инфрастуктура

Каждый из микросервисов является частью системы, а система должна уметь разворачивать сервисы, собирать логи, мониторить и прочие обязательные в таких случаях манипуляции. Если данный функционал обязателен для каждого сервиса, то не глупо его писать (реализовывать) каждый раз сначала? Если говорить в контексте микросервисной архитектуры, то все микросервисы, так или иначе "похоже" друг на друга, с точки зрения инфраструктуры использования. Следовательно, заложив основу можно из одного общего создать другой шаблон более специализированный, который предназначен для более узкого круга задач: прокси сервис, gateway-сервис и т.д. Другое дело, если существует потребность создать шаблоны для разных платформ: ASP.NET Core, WPF, WinForm и т.д.

Заключение

В связи с выше сказанным, хочу предложить вашему вниманию свой шаблон, вернее сказать шаблоны, для микросервисов, который я назвал Nimble Framework. Его исходные тексты можно найти в github, где помимо исходных файлов еще куча полезной информации.

Версии шаблонов

• Для ASP.NET Core 2.х больше не поддерживается
• Для ASP.NET Core 3.0 больше не поддерживается
• Для ASP.NET Core 3.1 доступны сборка без исходных файлов. Поддержка прекратится с выходом новой версии.
• Для ASP.NET 5.х доступны сборка без исходных файлов. 
  • Подробное описание шаблона v.5
• Nimble Framework 6.0: Для ASP.NET 6.0 Full API
• Nimble Framework 6.0: Для ASP.NET 6.0 Minimal API
• Nimble Framework 6.1: Для ASP.NET 6.0 с поддержкой OpenIddict (реализация закончена, идет формирование шаблонов)

Ссылки

• Почему Vertical Slice Architecture лучше чем "луковая"
• C# Coding Standards and Naming Conventions
• Микросервисы: Реализация
• Restructuring to a Vertical Slice Architecture