В данной статье вы узнаете о том, что инверсию зависимостей между бизнес-правилами и хранилищем данных реализуют на разную глубину, и варианты различаются не правильностью, а объёмом кода и тем, сколько сведений о базе данных остаётся в коде правил. Мы разберём три из них: привычный, где готовый интерфейс хранилища из фреймворка подключается прямо к правилам; вариант с отдельной моделью, где у правил есть и собственный интерфейс к хранилищу, и собственные классы данных, не связанные с таблицами; и переходный - с собственным интерфейсом, но прежними классами. Отдельно и подробно рассмотрен выбор между ними и переход от одного к другому. Вы также познакомитесь со способами удержать границу между правилами и хранилищем и с вопросом, по которому видно, какие методы хранилища переводить на интерфейс правил нужно, а какие нет.

В данной статье вы узнаете о том, что объектно-ориентированное программирование даёт архитектору контроль над направлением зависимостей в исходном коде, и почему из всего набора его средств этот контроль оказывается главным. Мы разберём три понятия, которыми принято определять такой подход - инкапсуляцию, наследование и полиморфизм, - и выясним, что архитектурную работу выполняет лишь одно из них. Отдельно и подробно рассмотрен полиморфизм: его устройство на уровне указателей на функции и приём инверсии зависимости, который он открывает. Вы также познакомитесь с архитектурой сменных модулей, где база данных и пользовательский интерфейс становятся плагинами к бизнес-правилам, узнаете о типичной ошибке при объявлении интерфейса и о границах применимости приёма.

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

В этой статье вы узнаете, чем ChatGPT, Claude и Gemini принципиально отличаются друг от друга при работе с кодом. Мы разберём сильные и слабые стороны каждой модели и сравним их по ключевым техническим параметрам. И что самое важное - вы получите не готовый ответ на вопрос «какой инструмент лучше», а понимание того, в каких сценариях разработки уместнее использовать ту или иную модель.

При смене хостинга, передаче проекта заказчику или выходе в open source часто возникает необходимость перенести код в новый репозиторий. В этой статье мы рассмотрим, как сделать это чисто: обнулить историю коммитов и перенести на новый сервер только актуальное состояние проекта. Мы не будем использовать сторонние утилиты или сложные скрипты - задача элегантно решается стандартными средствами Git.

В данной статье вы познакомитесь с основами AI Engineering и узнаете, с чего начать переход в эту область, если у вас уже есть опыт в классической разработке. Разберём базовые концепции — токены, эмбеддинги, температуру — и покажем, как они соотносятся с привычными инженерными понятиями. На простых примерах рассмотрим типизацию вывода языковых моделей, принципы работы агентов, паттерн RAG и основы управления состоянием. Главная идея: накопленные знания в области бэкенда, проектирования систем и паттернов проектирования не теряют своей ценности — они становятся фундаментом для работы с AI-инструментами. Статья не претендует на исчерпывающее руководство, но даёт отправную точку для тех, кто хочет сделать первые шаги в AI Engineering, опираясь на то, что уже умеет.

В данной статье вы узнаете о том, что такое архитектура программного обеспечения и зачем она нужна на практике. Мы разберём, почему качество структуры системы напрямую влияет на скорость и стоимость разработки, к каким последствиям приводит пренебрежение архитектурой ради быстрого запуска продукта, и чем грозит накопленный технический долг. Вы также познакомитесь с двумя ключевыми ценностями любого программного продукта — поведением и структурой — и поймёте, почему гибкость системы в долгосрочной перспективе важнее идеального функционала в моменте. Отдельное внимание уделено тому, как разработчику выстраивать аргументированный диалог с руководством и обосновывать важность архитектурных решений на языке бизнеса.

Возвращать необработанные JPA-сущности из REST-контроллеров — это один из тех паттернов, который кажется безобидным в начале, но затем превращается в системную проблему в production. Он не просто нарушаете принцип разделения ответственности — он создаёт три взаимосвязанных риска одновременно: утечку чувствительных данных, жёсткую связанность API со схемой БД и потерю контроля над публичным контрактом. В этой статье мы разберём пять паттернов, которые используют опытные разработчики. Каждый из них решает конкретную задачу, и вместе они формируют слой ответов, который является одновременно безопасным, производительным и удобным в сопровождении.