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 Pressure: The Invisible Hand That Shapes Your Code
https://hynek.me/talks/design-pressure/
#ycombinator #Python #OOP #object_oriented_code #software_design #design_pressure #ORM #Pydantic

Keeping it Old-Tool: REPL habits of a grug-brained Clojure programmer
https://www.evalapply.org/posts/demo-clojure-workflow-scicloj/index.html
#ycombinator #systems_thinking #functional_programming #architecture #software_design #technology_leadership #devops #clojure #B2B_Micro_SaaS

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

Статья представляет собой перевод статьи отсюда , на которую я натолкнулся в процессе изучения темы системного проектирования. В системном дизайне понимание разницы между классами проектирования (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

How to think about software quality (2022)
https://www.evalapply.org/posts/how-to-not-die-by-a-thousand-cuts/index.html
#ycombinator #systems_thinking #functional_programming #architecture #software_design #technology_leadership #devops #clojure

How to Not Die by a Thousand Cuts. Or How to Think About Software Quality (2022)
https://www.evalapply.org/posts/how-to-not-die-by-a-thousand-cuts/index.html
#ycombinator #systems_thinking #functional_programming #architecture #software_design #technology_leadership #devops #clojure

O-Mase
(2010) : DeLoach, Scott A. Ojeda, Juan ...
DOI: https://doi.org/10.1504/ijaose.2010.036984
#o_MaSE #IDE #software_design #agentTool_III #methodology #HCI #complexity #adaptive #MAS #my_bibtex

Is your codebase in need of a makeover? SOLID principles are your solution. Join us as we dissect these principles, learn how you can revamp your software development process.

Check out the full article👇
https://blog.lab.sa/what-are-solid-principles

#Software_Development
#Coding_Best_Practices
#Software_Design
#Programming
#Clean_Code
#Code_Quality
#SOLID_Principles

Cold restart whole system after total outage
https://www.evalapply.org/posts/cold-restart-total-outage/index.html
#ycombinator #systems_thinking #functional_programming #architecture #software_design #technology_leadership #devops #clojure

O-Mase
(2010) : DeLoach, Scott A. Ojeda, Juan ...
DOI: https://doi.org/10.1504/ijaose.2010.036984
#adaptive #IDE #complexity #HCI #o_MaSE #agentTool_III #MAS #software_design #methodology #my_bibtex

A Field Study of the Software Design Process for Large Systems
(1988) : Curtis, Bill Krasner, Herb Isc...
DOI: https://doi.org/10.1145/50087.50089
#large_scale #software_design #software_engineering #my_bibtex

A Field Study of the Software Design Process for Large Systems
(1988) : Curtis, Bill Krasner, Herb Isc...
DOI: https://doi.org/10.1145/50087.50089
#software_design #software_engineering #large_scale #my_bibtex

The Complete Hypercard Handbook
(1988) : Goodman, Danny
isbn: 0-553-34577-X
#history #apple #hypertext #authoring #HCI #software_design #hypercard #authoring_tools #my_bibtex

A pattern reinvented again and again:

Save a query as a "virtual folder" so that users can automatically get aggregated "file" list from the entire system according a set of criteria.

macOS -> SmartFolder
https://support.apple.com/en-ca/guide/mac-help/mchlp2804/mac

DevonThink -> Smart Rules
https://www.devontechnologies.com/blog/20201110-organize-with-smart-rules

jabref -> Extra kinds of grouping
https://docs.jabref.org/finding-sorting-and-cleaning-entries/groups#searching-for-a-keyword-in-a-field

Zotero -> Saved Search
https://www.zotero.org/support/searching#saved_searches

#software_design #desktop_ui

A Field Study of the Software Design Process for Large Systems
(1988) : Curtis, Bill and Krasner, Herb and Iscoe, Neil
DOI: https://doi.org/10.1145/50087.50089
#large_scale #software_design #software_engineering
#my_bibtex

A primary difference between macOS's toolbar and GNOME's head-bar is that the former is editable.

A macOS Developer can implement ALL of possible functionalities and put only 20% on toolbar as default.

Advanced users can opt-in more tools for toolbar.

The GNOME's header bar is fixed. A Developer is forced to only put a limited set of tools there, and there is no space for advanced user.

A direct influence is that all GNOME applications are very primitive, because a dev cannot explore more operations and limit their vision on limited space.

KDE do have an editable toolbar, but the current UI aren't intuitive.

Related: https://pilky.me/appreciating-appkit-part-1/

#software_design