[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"question-arkhitektura-prilozheniy-kak-printsipy-solid-primenyayutsya-v-kontekste-arkhitektury":3},{"id":4,"slug":5,"topicId":6,"topicSlug":7,"topicName":8,"topicEmoji":9,"question":10,"answer":11,"codeLang":12,"codeSrc":12,"important":12,"commonMistakes":12,"modernUsage":12,"difficulty":13,"tags":14,"related":19,"progress":20,"seo":21},123,"kak-printsipy-solid-primenyayutsya-v-kontekste-arkhitektury",3,"arkhitektura-prilozheniy","Архитектура приложений","🏗️","Как принципы SOLID применяются в контексте архитектуры","SOLID — пять принципов объектно-ориентированного проектирования, которые применимы не только на уровне классов, но и на уровне модулей и компонентов системы.\n\n### S — Single Responsibility Principle (Принцип единственной ответственности)\n\nНа уровне архитектуры: каждый модуль или сервис отвечает за одну бизнес-область.\n\n```java\n\u002F\u002F Плохо: один сервис делает всё\n@Service\npublic class MegaService {\n    public void createPayment(...) { }\n    public void generateReport(...) { }\n    public void sendNotification(...) { }\n}\n\n\u002F\u002F Хорошо: разделение ответственности\n@Service public class PaymentService { ... }\n@Service public class ReportService { ... }\n@Service public class NotificationService { ... }\n```\n\nВ микросервисной архитектуре SRP определяет границы сервисов: сервис платежей, сервис уведомлений, сервис отчётов.\n\n### O — Open\u002FClosed Principle (Принцип открытости\u002Fзакрытости)\n\nНа уровне архитектуры: система открыта для расширения, но закрыта для модификации. Новые возможности добавляются через новые модули, а не через изменение существующих.\n\n```java\n\u002F\u002F Стратегия расчёта комиссии — расширяем через новую реализацию\npublic interface CommissionStrategy {\n    Money calculate(Payment payment);\n}\n\n@Component public class StandardCommission implements CommissionStrategy { ... }\n@Component public class VipCommission implements CommissionStrategy { ... }\n\u002F\u002F Новый тип — просто добавляем класс, не меняя существующий код\n@Component public class CorporateCommission implements CommissionStrategy { ... }\n```\n\n### L — Liskov Substitution Principle (Принцип подстановки Барбары Лисков)\n\nНа уровне архитектуры: любой компонент, реализующий интерфейс (порт), может быть заменён другой реализацией без нарушения работы системы. Например, замена PostgreSQL-репозитория на MongoDB-репозиторий не должна ломать бизнес-логику.\n\n### I — Interface Segregation Principle (Принцип разделения интерфейсов)\n\nНа уровне архитектуры: API модулей и сервисов должны быть узкоспециализированными. Клиент не должен зависеть от методов, которые он не использует.\n\n```java\n\u002F\u002F Плохо: один «жирный» интерфейс\npublic interface AccountOperations {\n    Account findById(Long id);\n    void transfer(Long from, Long to, BigDecimal amount);\n    Report generateMonthlyReport(Long accountId);\n    void blockAccount(Long id);\n}\n\n\u002F\u002F Хорошо: разделённые интерфейсы\npublic interface AccountQueryPort { Account findById(Long id); }\npublic interface TransferPort { void transfer(TransferCommand cmd); }\npublic interface AccountAdminPort { void blockAccount(Long id); }\n```\n\n### D — Dependency Inversion Principle (Принцип инверсии зависимостей)\n\nНа уровне архитектуры: это фундамент гексагональной и чистой архитектуры. Модули высокого уровня (бизнес-логика) не зависят от модулей низкого уровня (инфраструктура). Оба зависят от абстракций.\n\n```\nБез инверсии:               С инверсией:\nService → JpaRepository      Service → Repository (интерфейс)\n                                              ↑\n                              JpaRepository реализует Repository\n```\n\n> **На собеседовании:** Интервьюер хочет услышать примеры применения SOLID именно на архитектурном уровне (модули, сервисы), а не только на уровне классов. Частая ошибка — пересказывать определения принципов, не показывая, как они влияют на структуру системы.","","middle",[15,16,17,18],"oop","solid","design-principles","architecture",[],null,{"title":22,"description":23,"ogTitle":22,"ogDescription":24,"keywords":25,"schemaAnswer":34,"featuredSnippetReady":35},"Принципы SOLID в контексте архитектуры — Gymterview","Применение пяти принципов SOLID на уровне архитектуры: SRP для границ сервисов, OCP для расширяемости, LSP, ISP и DIP для модулей. Примеры на Java.","Применение принципов SOLID на уровне модулей и компонентов архитектуры. Примеры на Java.",[26,27,28,29,30,31,32,33],"SOLID архитектура","принципы SOLID","SRP","OCP","LSP","ISP","DIP","инверсия зависимостей","SOLID применимы не только на уровне классов, но и на уровне модулей и компонентов. SRP определяет границы сервисов (каждый модуль отвечает за одну бизнес-область). OCP — система расширяется через новые модули, а не через изменение существующих. LSP — любой компонент, реализующий порт, может быть заменён другой реализацией. ISP — API модулей должны быть узкоспециализированными. DIP — фундамент гексагональной и чистой архитектуры: бизнес-логика не зависит от инфраструктуры, оба зависят от абстракций.",true]