Какие принципы надо помнить продактам при разработке архитекту | Fresh Product Manager

Какие принципы надо помнить продактам при разработке архитектуры решения?

SRP - Принцип единой ответственности (The Single Responsibility Principle). Соберите воедино то, что меняется по одним и тем же причинам. Разделяйте вещи, которые меняются по разным причинам. Мы не смешиваем бизнес-правила с кодом графического интерфейса. Мы не смешиваем SQL-запросы с протоколами связи. Мы храним код, который изменяется по разным причинам, отдельно, чтобы изменения одной части не нарушали работу других частей. Мы следим за тем, чтобы модули, которые изменяются по разным причинам, не имели запутывающих их зависимостей.

OCP - Принцип открытости-закрытости (The Open-Closed Principle). Модуль должен быть открыт для расширения, но закрыт для модификации. Из всех принципов, мысль о том, что кто-то поставит под сомнение этот, наполняет меня страхом за будущее нашей отрасли. Конечно, мы хотим создавать модули, которые можно расширять, не изменяя их. Можете ли вы представить себе работу в системе, в которой отсутствует независимость от устройств, где запись в файл на диск принципиально отличается от записи на принтер, экран или канал? Хотим ли мы увидеть, рассредоточен ли оператор по нашему коду, чтобы иметь дело со всеми мелкими деталями?

LSP - Принцип подстановки Лисков (The Liskov Substitution Principle). Программа, использующая интерфейс, не должна быть сбита с толку реализацией этого интерфейса.
Люди (в том числе и я) совершили ошибку, сказав, что речь идет о наследовании. Все реализации интерфейсов являются подтипами интерфейса. Каждый пользователь базового интерфейса, заявленный или подразумеваемый, должен согласовать значение этого интерфейса. Если реализация вводит в заблуждение пользователя базового типа, тогда операторы if / switch будут распространяться по коду.

ISP - Принцип разделения интерфейса (The Interface Segregation Principle). Делайте интерфейсы небольшими, чтобы пользователи не зависели от ненужных вещей. Клиенты действительно зависят от методов, которые они не вызывают, если их нужно перекомпилировать и повторно развернуть при изменении одного из этих методов.

DIP - Принцип инверсии зависимостей (The Dependency Inversion Principle). Модули высокого уровня не должны зависеть от деталей низкого уровня. Мы не хотим, чтобы наши бизнес-правила высокого уровня зависели от деталей низкого уровня. Мы не хотим, чтобы вычисления, приносящие нам деньги, были загрязнены SQL, низкоуровневыми проверками или проблемами форматирования. Мы хотим изолировать абстракции высокого уровня от деталей низкого уровня.

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

Ответьте на 11 вопросов и узнайте, достаточно ли у вас знаний, чтобы пройти онлайн-курс «Software Architect» в OTUS по спец.цене. Успешное прохождение теста откроет доступ к 2 урокам курса: Модели межсервисного взаимодействия и Архитектурное свойство "Сопровождаемость" на примере сервисов k8s
Пройти тест - https://otus.pw/8L5S/