Minimal API: Избавляемся от устаревающих контроллеров в ASP.NET Core

Я, думаю, многие уже слышали о появившихся в .NET 6 Minimal API - легковесной замене контроллеров/MVC. Кто-то уже успел ознакомиться и задался вопросом: "Ваше API в 3 строчки, это, конечно, здорово, но как это будет работать в реальном проекте с сотнями эндпоинтов, кучей фильтров, аттрибутов, расширениями OpenAPI/Swagger и прочих радостях?" В этой статье я хочу ответить на этот вопрос: пройдемся от основ, преимуществ, недостатков, и закончим нюансами работы и проблемами, которые обязательно возникнут при миграции с контроллеров на Minimal API в крупном проекте. А забегая чуть вперед: если думаете, стоит ли переводить проект на Mini API, вот вам сразу полезная информация: они могут жить в проекте вместе, причем даже без дублирования инфраструктуры: не обязательно переводить все разом - подробнее под катом. Бонусом, заменим SwaggerGen на реализацию OpenAPI от Microsoft.

https://habr.com/ru/articles/917378/

#c# #net #minimal_api #mvc #api #software_design #openapi #swagger

Vertical Slice Architecture на примере C# — простая и удобная архитектура для небольших (и не только) пректов

Простой вопрос: делая задачу, касающуюся API - вы чаще работаете с одним эндпоинтом, или пишите, условные, репозитории, которые используются сразу в нескольких эндпоинтах? Скорее всего, первое, тогда почему мы разбиваем проект по слоям, а не по фичам (эндпоинтам)? Это видно в часто используемых нынче архитектурных подходах: Layered, Clean Architecture, Onion, и так далее. Не буду выделять что-то конкретное и объясню общую разницу в подходах: Vertical Slice Architecture (VSA) строится вокруг каждого отдельного feature-слайса (эндпоинта, как самый простой пример), а не на вокруг слоев. То есть, если код относится к конкретному эндпоинту, мы не размазываем его по всему проекту в папках Commands/Services/Repositories/DTOs и т.п., а кладем в одно место, там где и будет находиться эндпоинт Главный принцип - уменьшаем связанность между слайсами (фичами), увеличиваем связанность внутри слайса

https://habr.com/ru/articles/916704/

#c# #vertical_slice #minimal_api #архитектура #net #software_design

[Перевод] Классы проектирования против классов анализа

Статья представляет собой перевод статьи отсюда , на которую я натолкнулся в процессе изучения темы системного проектирования. В системном дизайне понимание разницы между классами проектирования (design classes) и классами анализа (analysis classes) носит ключевой характер. Классы анализа подобны детективу — они исследуют и понимают проблему. Они сфокусированы на том, что система должна делать, без погружения в то, как именно это должно быть реализовано. Эти классы помогают разработчикам понять требования к программе и ее цели. В то время как классы проектирования подобно архитектору берут результаты изысканий классов анализа и создают план, как именно система будет работать.

https://habr.com/ru/articles/885906/

#software_design #oop #analysis #theory

エディタ選びのポイント、ITエンジニア人生を左右するツールのいろは——Software Design 2025年3月号の特集記事を先行公開
https://gihyo.jp/article/2025/02/choosing-editor-for-engineer?utm_source=feed

#gihyo #技術評論社 #gihyo_jp #Software_Design #Vim #Emacs #VS_Code #Editor

Пример создания Full Stack проекта, используя функциональное тестирование как инструмент дизайна

Зачастую full stack (и не только) проекты создаются без функциональных тестов. Это вызвано ошибочным предположением, что тесты добавляются для уже готового продукта и они нужны только для поддержки качества. Необходимость в тестах также возникает, когда количество багов или жалоб пользователей переходит все границы. В такой ситуации разработчики проекта решают добавлять тесты, и тут выясняется, что это не так просто, как большинство думает. Проблема сложности тестов в подобной ситуации кроется в том, что на этапе проектирования продукта никто не думал о его тестировании и необходимости сделать его пригодным для тестирования (автоматического). На этапе проектирования самого продукта гораздо проще проектировать тесты, потому что вы не ограничены существующим кодом продукта, фреймворками и утилитами, входящими в состав продукта. В этой части статьи я на примере покажу, как можно спроектировать простое веб-приложение, используя функциональное тестирование, и имплементировать веб-приложение. Поехали!

https://habr.com/ru/articles/846046/

#automationtesting #functional_testing #web_developement #tdd #architecture #fullstack_development #software_development #software_design

I've been talking about App & Architecture Modernization, Service Blueprints, etc, but I've not been very good at writing about it. Thanks to my good friends @crichardson and @diana I plan to!

Here’s my first post:

https://domainanalysis.io/p/application-and-architecture-modernization

#architecture_design modernization #software_design