SOLID принципы: что это такое и зачем они нужны цифровому продукту

Что нужно знать про SOLID бизнесу?

Для владельца продукта название каждого принципа само по себе не так важно. Гораздо важнее последствия архитектурных решений.

Если система организована последовательно, команде проще:

• добавлять новые функции;

• менять существующие бизнес-процессы;

• подключать внешние сервисы;

• тестировать изменения;

• заменять отдельные компоненты;

• передавать проект другой команде;

• развивать разные части продукта параллельно;

• контролировать технический долг.

Например, интернет-магазин сначала работает с одним платёжным сервисом. Через некоторое время бизнес хочет добавить СБП и ещё одного провайдера.

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

Поэтому практический смысл SOLID можно сформулировать так: чем проще локализовать изменения, тем проще управлять развитием продукта.

Как SOLID влияет на стоимость разработки?

Стоимость цифрового продукта складывается не только из его первоначального создания. После запуска компания продолжает платить за поддержку, исправление ошибок, новые функции и интеграции.

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

SOLID помогает уменьшать количество таких лишних связей.
 

Добавление новых функций

Когда ответственность между компонентами распределена понятно, разработчику проще определить, где нужно изменить систему.

Например, добавление нового способа доставки не должно заставлять переделывать всю логику заказа, если эти части правильно разделены.
 

Замена интеграций

Компания может сменить:

• CRM;

• платёжный сервис;

• службу доставки;

• систему аналитики;

• email-провайдера;

• поставщика инфраструктуры.

Если бизнес-логика напрямую зависит от конкретного сервиса, переход может оказаться трудоемким. Если зависимость изолирована, ее проще заменить.
 

Поддержка

Когда каждому компоненту отведена понятная роль, легче определить, где искать причину проблемы и какую часть системы нужно изменить.
 

Работа нескольких команд

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

Передача проекта

Если бизнес меняет подрядчика или расширяет команду, хорошо разделенная система обычно быстрее осваивается новыми специалистами.

При этом SOLID сам по себе не гарантирует снижение затрат. Результат зависит от качества архитектуры, требований продукта, тестирования и того, насколько последовательно команда применяет принципы.

5 принципов SOLID

S — принцип единственной ответственности

Single Responsibility Principle (SRP) часто формулируют как принцип единственной ответственности.

Проще для бизнеса его можно объяснить так: один компонент должен отвечать за одну понятную область и иметь ограниченное число причин для изменения.

Представим интернет-магазин. В одном большом модуле находится:

• расчет заказа;

• применение скидок;

• оплата;

• отправка уведомлений;

• формирование отчётов.

Пока система небольшая, такой подход может работать. Но по мере развития продукта этот компонент становится всё сложнее менять.

Если нужно изменить правила скидок, разработчик работает с модулем, который одновременно отвечает за оплату и уведомления.

Такой чрезмерно большой компонент иногда называют God Object.

При соблюдении SRP разные задачи распределяются между отдельными компонентами. Это позволяет локализовать изменения.

O — принцип открытости и закрытости

Open/Closed Principle (OCP) предполагает, что систему стоит проектировать с возможностью расширения без постоянной переделки уже работающего кода.

Допустим, интернет-магазин поддерживает оплату картой. Затем бизнес добавляет:

• СБП;

• электронные кошельки;

• рассрочку;

• нового платежного провайдера.

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

При другом подходе каждый новый способ оплаты может быть отдельной реализацией общего контракта. Основная логика оформления заказа при этом остаётся прежней.

Для реализации OCP могут применяться разные паттерны проектирования, например Strategy или Factory. Но сам паттерн не является целью. Важнее получить архитектуру, в которой расширение продукта не требует постоянной перестройки его основы.
 

L — принцип подстановки Лисков

Liskov Substitution Principle (LSP) связан с тем, как разные реализации одного компонента взаимодействуют с остальной системой.

Идея появилась в работах Барбары Лисков и Джанет Винг о поведенческой совместимости подтипов. В их исследовании сформулирован принцип, согласно которому свойства, ожидаемые от базового типа, должны сохраняться и для его подтипов.

Это можно представить на примере служб доставки.

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

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

Поэтому LSP можно рассматривать как принцип предсказуемости заменяемых компонентов.

Он особенно важен для систем, где есть:

• несколько платёжных сервисов;

• разные службы доставки;

• несколько поставщиков данных;

• внешние API;

• альтернативные реализации одного сервиса.
   

I — принцип разделения интерфейсов

Interface Segregation Principle (ISP) говорит о том, что компонент не должен зависеть от большого интерфейса, если ему нужна только небольшая часть его возможностей.

Представим корпоративную систему с единым интерфейсом работы с клиентами. Со временем в него добавили операции для:

• создания клиента;

• изменения данных;

• экспорта;

• отчетности;

• уведомлений;

• работы с документами.

Но конкретному модулю нужен только просмотр информации.

Если он зависит от всего большого интерфейса, изменение ненужной для него функции может затронуть и этот модуль.

Поэтому интерфейсы разделяют на более узкие области.

Для цифрового продукта это значит меньше лишних зависимостей между частями системы.

Чем сложнее проект и чем больше в нём модулей, тем важнее контролировать такие связи.
 

D — принцип инверсии зависимостей

Dependency Inversion Principle (DIP) предполагает, что основная бизнес-логика не должна быть жестко привязана к конкретным техническим реализациям.

Например, обработка заказа не должна напрямую зависеть от конкретного платёжного сервиса или поставщика email-рассылок.

Представим, что компания решила:

• заменить CRM;

• сменить платежного провайдера;

• перейти на другую СУБД;

• изменить сервис уведомлений;

• вынести часть функциональности в отдельный сервис.

Если бизнес-логика тесно связана с конкретной технологией, изменение затронет большое количество кода.

При DIP между бизнес-логикой и конкретными реализациями используется абстракция. Это позволяет менять технические компоненты с меньшим количеством изменений в основной логике.

На практике для управления зависимостями применяется dependency injection — внедрение зависимостей.

Здесь смысл: продукт не должен становиться заложником конкретного технического решения, если его можно заменить.

Ниже сделали общую схему пяти принципов.

Когда архитектура влияет на развитие продукта?

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

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

Пример от LighTech

Похожая задача возникла при разработке MVP мобильного приложения МТС Travel. Продукт нужно было создать с нуля и выпустить всего за три месяца. При этом приложение должно было поддерживать авторизацию через МТС ID, работу с МТС Cashback, разные пользовательские сценарии и взаимодействие с веб-сервисами.

Как понять, что архитектура уже мешает бизнесу?

Проблемы с архитектурой обычно становятся заметны не по нарушению конкретного принципа SOLID, а по тому, как меняется сам процесс разработки. Если команде приходится тратить всё больше времени даже на небольшие доработки, а согласование и проверка изменений занимают значительную часть работы, стоит разобраться в причинах. 

Ещё один сигнал — ситуация, когда разработчики опасаются менять отдельные участки системы, потому что не могут заранее оценить последствия. По мере роста продукта такие сложности накапливаются: новые функции начинают требовать всё больше ресурсов, а скорость развития снижается.

Если такие признаки появляются регулярно, не обязательно сразу переписывать приложение.

Сначала стоит провести технический аудит, определить наиболее проблемные участки и оценить, какие изменения действительно дадут бизнесу результат.

Когда не стоит усложнять архитектуру?

Для небольшого одноразового скрипта сложная архитектура может быть неоправданной.

Если программа:

• решает одну конкретную задачу;
• не предполагает дальнейшего развития;
• почти не имеет интеграций;
• используется ограниченное время,

то большое количество абстракций может только увеличить объём работы.

Похожая ситуация возможна на этапе раннего прототипа.

Когда команда проверяет бизнес-гипотезу, не всегда рационально строить архитектуру полноценного продукта заранее.

Но если уже понятно, что после MVP система будет активно развиваться, стоит хотя бы выделить основные бизнес-области и критичные интеграции.

SOLID и MVP: как найти баланс

На этапе MVP не обязательно строить сложную многоуровневую архитектуру.

Но и полностью игнорировать будущие изменения тоже рискованно.

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

• заказ;
• расчёт стоимости;
• оплату;
• доставку;
• уведомления.

При этом архитектура может оставаться достаточно простой.

Хороший ориентир — не строить систему на гипотетическое будущее, но не создавать лишних ограничений для уже очевидных сценариев развития продукта.

Что обсудить с разработчиками до начала проекта?

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

Также стоит уточнить, как команда планирует работать с техническим долгом, передавать проект другим специалистам и адаптировать архитектуру при росте нагрузки. Ответы на эти вопросы помогут понять, думает ли команда только о запуске первой версии или учитывает дальнейшее развитие и поддержку продукта.

Какие есть ошибки при использовании SOLID?

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

Не стоит применять SOLID одинаково к любому проекту: архитектура MVP, внутреннего корпоративного инструмента и долгосрочного SaaS-продукта может строиться по-разному. Наконец, даже удачно спроектированная система со временем меняется вместе с бизнесом, поэтому архитектуру необходимо периодически пересматривать и рефакторить при появлении новых требований и сценариев.

Что важно запомнить?

SOLID — это пять принципов проектирования программного обеспечения, которые помогают контролировать сложность системы по мере её развития.

Их ценность для бизнеса заключается не в том, чтобы сделать код «идеальным». Гораздо важнее возможность менять продукт без постоянной переделки уже работающих частей.

Если система несколько лет развивается, получает новые функции и интеграции, архитектура начинает влиять на стоимость её поддержки и скорость изменений.

Поэтому при разработке долгосрочного продукта стоит заранее продумать:

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

SOLID не должен становиться самоцелью. Хорошая архитектура — это не максимальное количество классов и интерфейсов, а разумная организация системы, которая соответствует задачам продукта.