PostgreSQLの並列処理とJIT ――実行計画からひも解く処理特性と導入効果
https://gihyo.jp/article/2026/03/postgresql-parallel-jit?utm_source=feed

#gihyo #技術評論社 #gihyo_jp #Software_Design #PostgreSQL_18 #並列処理 #JIT #MVCC

Agentic Feature Owners: AI 에이전트와 기능 소유권에 관한 새로운 팟캐스트

Avdi Grimm과 Jessitron이 AI 에이전트가 소프트웨어 기능의 소유권을 갖는 'Agentic Feature Owners' 개념을 다루는 새로운 팟캐스트 에피소드를 공개했다.

🔗 원문 보기

Объединяем уровни абстракции: обобщаем артефакты анализа для общего видения концепта задачи

Добрый день, дорогие читатели! Поделюсь с вами опытом составления артефакта, который объединяет уровни абстракции проектируемого решения в одном месте: развертка вариантов использования по статусной модели с маппингом на API.

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

#архитектура_системы #архитектура_по #системный_анализ #проектирование_систем #software_design #бизнесанализ #бизнеспроцессы #статусная_модель #use_case #api

ADR, архитектурные тесты и кейсы из прода: ресурсы, которые реально меняют код

У меня была привычка. Вижу классную статью про архитектуру —-сохраняю. Репозиторий с примерами DDD - в закладки. Видео про CQRS - в плейлист «Посмотреть потом». Вы знаете, чем кончаются плейлисты «Посмотреть потом». В какой-то момент закладок стало 300+. Половина ссылок битые, треть дублируют друг друга, остальное - статьи, которые казались гениальными в два часа ночи. Я сел и вычистил всё до 106 ресурсов. Собрал их в awesome-list на GitHub . Но статья не про список. Статья про три вещи, которые я для себя открыл в процессе и которые почему-то мало обсуждают.

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

#architecture #DDD #CQRS #clean_architecture #ADR #software_design #software_architecture #best_practices #system_design #microservices

RUG — малоизвестный, но фундаментальный принцип Clean Code

Многие разработчики при обсуждении основ Clean Code называют одни и те же принципы — чаще всего упоминаются DRY , KISS и YAGNI . Эти концепции прочно закрепились в профессиональном сообществе и воспринимаются как обязательная часть хорошего кода. Принцип RUG упоминается значительно реже. Чаще всего о нём узнают с опытом, а многие применяют его интуитивно, даже не подозревая, что для этого подхода существует отдельное название и формулировка. Сегодня я хочу поговорить о принципе RUG и о том, какие рекомендации он даёт по написанию программного обеспечения. RUG ( Repeat Until Good ) — это принцип, который говорит: можно повторять один и тот же код, пока это разумно. На ранних этапах разработки важнее просто реализовать логику, исходя из текущих требований, чем пытаться сразу создать «идеальную» абстракцию. В этот момент задача — как можно быстрее получить рабочее решение, которое отражает текущие знания о системе. Но со временем, когда одна и та же логика начинает встречаться всё чаще, становится очевидно, что её удобнее и правильнее выделить в отдельную, чётко оформленную абстракцию, чтобы избежать дублирования и упростить дальнейшую поддержку. Мы используем этот принцип каждый раз, когда пишем код. Ведь практически любую логику можно сделать более абстрактной и масштабируемой — вопрос лишь в том, когда наступает подходящий момент для этого. Я буду использовать TypeScript , так как этот язык знаком большинству разработчиков. 😁

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

#rug #cleancode #programming #software_design #patterns #refactoring #typescript

[Перевод] Архитектурные принципы

Сегодня я бы хотел представить вам архитектурные принципы, которыми я руководствуюсь при создании приложений. Я считаю, что эти принципы применимы к подавляющему большинству приложений, за редкими исключениями. И даже несмотря на то, что каждый из них является фундаментальным, я в своей практике раз за разом замечаю, как люди напрочь про них забывают. И так как я не видел, чтобы они были где-либо представлены в едином коротком виде, я решил сделать это тут. Итак, без долгих предисловий:

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

#architecture #software_design #архитектура_приложений #дизайн_программного_обеспечения #архитектура_по #принципы_проектирования #проектирование_систем #architecture_principles #принципы_разработки

Преодоление сложности в самом сердце Анемичной Модели

Доброго времени суток, Хабр! Сегодня хотел бы поговорить об анемичной модели — одном из самых дискуссионных топиков (особенно для приверженцев DDD) и о том, как, по моему мнению, правильно её готовить. Для кого-то анемичная модель — это антипаттерн, тогда как для других это единственный правильный способ реализации приложений. Многие использовали её годами и даже не знали, как она называется, и что кем-то она считается антипаттерном. Реальность же такова, что анемичная модель — это инструмент, который может подходить или не подходить в зависимости от ситуации, но при этом является очень популярным и, по факту, «стандартом де-факто» для многих программистов и организаций. Хотя в последние годы я и вижу тенденцию к тому, что DDD и, соответственно, богатая доменная модель становятся всё популярнее, пока что, по моему мнению, им далеко до популярности анемичной модели.

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

#ddd #software_design #anemic_model #refactoring #architecture #java #oop #web_development #domain_driven_design #functional_programming

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