О чем этот материал
Чистая архитектура, гексагональный подход, микросервисы, события и SOLID без лишнего пафоса.
Это адаптированная версия учебной презентации: слайды разобраны в формате обычной статьи, чтобы материал было легче читать с телефона и возвращаться к нужным блокам позже.
Что внутри
Ниже краткий план материала. По нему удобно понять, в каком порядке разбирать тему.
- Зачем нужна архитектура
- Какие бывают
- SOLID
Архитектура это не только структура системы, но и набор решений, которые помогут сделать систему гибкой, легко поддерживаемой и
расширяемой.
Архитектура
конкретным технологиям.
- Независимость от инфраструктуры. Архитектура не должна быть привязана к
- Возможность тестирования. Каждый компонент должен быть легко тестируемым.
- Независимость от UI или внешних API
- Поддерживаемость. Продукт должен иметь возможность развиваться и расти
Какие бывают
Чистая архитектура (Clean Architecture)
внешних компонентов.
разделении на слои, где наиболее важный — это ядро приложения (сущности и бизнесправила). Далее идут use cases (сценарии
использования), а внешние системы, такие как UI или базы данных, размещаются на внешних слоях.
- Принципы: Стремится отделить бизнес-логику от инфраструктуры. Основная идея — бизнеслогика должна быть независимой от пользовательского интерфейса, базы данных и других
- Структура: Архитектура строится на
- Цель: Минимизировать зависимости и сделать
- Принципы: Внешние системы (например, базы данных, веб-интерфейсы, API) подключаются к
- Структура: Центром системы является ядро
- Цель: изолировать бизнес-логику от
SOLID
SOLID-принципы обеспечивают правильное разбиение системы на компоненты и минимизируют связанность между ними. Эти принципы помогают строить
архитектуру, где модули легко заменяемы и расширяемы.
Single Responsibility Principle (SRP)
Принцип единственной ответственности: Каждый модуль или класс должен иметь только одну причину для изменения, то есть выполнять только одну задачу.
Open/Closed Principle (OCP)
Принцип открытости/закрытости: Программные сущности должны быть открыты для расширения, но закрыты для модификации.
Принцип открытости/закрытости: Программные сущности должны быть открыты для расширения, но закрыты для модификации.
Liskov Substitution Principle (LSP)
Принцип подстановки Лисков: Объекты в программе должны быть заменяемы экземплярами их подтипов без изменения правильности выполнения программы.
Interface Segregation Principle (ISP)
Принцип разделения интерфейсов: Клиенты не должны зависеть от интерфейсов, которые они не используют. Лучше иметь несколько специализированных интерфейсов, чем один общий.
Dependency Inversion Principle (DIP)
Принцип инверсии зависимостей: Модули высокого уровня не должны зависеть от модулей низкого уровня. Оба должны зависеть от абстракций. Абстракции не
должны зависеть от деталей. Детали должны зависеть от абстракций.
Проблема: EmailSender зависит от конкретного
SMTPClient, что затрудняет замену на другую реализацию или тестирование.
Еще раз коротко
SRP: Разделяйте обязанности, чтобы каждая структура или функция выполняла только одну задачу.
OCP: Используйте абстракции (интерфейсы) для расширения функциональности без изменения существующего кода.
LSP: Убедитесь, что подтипы могут заменять базовые типы без изменения корректности программы.
ISP: Разделяйте интерфейсы на более мелкие и специализированные, чтобы клиенты зависели только от необходимых им методов.