КАТЕГОРИЯ
Архитектура ПО
294 материалов
Закон КонвеяСтруктура создаваемой системы отражает структуру коммуникаций организации.Закон ГаллаРаботающая сложная система обычно развивается из работающей простой системы.Закон БруксаДобавление людей в опаздывающий программный проект может увеличить задержку.Технический долгУскорение сегодня может создать дополнительную стоимость изменений и сопровождения завтра.Закон ХайрамаЛюбое наблюдаемое поведение API со временем становится зависимостью.Закон протекающих абстракцийАбстракции иногда раскрывают детали нижележащей реализации.Сокрытие информацииМодуль должен скрывать решения, которые вероятнее всего изменятся.Разделение ответственностиНезависимые причины изменений должны быть разделены.Высокая связность внутри, низкая междуСвязанная логика должна быть рядом, а модули - зависеть друг от друга минимально.Законы эволюции ПО ЛеманаДолгоживущая система усложняется без постоянного упрощения.Эффект второй системыВторую версию часто перегружают всеми отложенными идеями.Большой ком грязиСистема превращается в массу зависимостей без ясной структуры.Эволюционная архитектураАрхитектура должна безопасно меняться вместе с требованиями.KISSПростые решения легче проверять, менять и эксплуатировать.YAGNIНе следует создавать функциональность до появления реальной необходимости.DRYКаждое знание должно иметь одно авторитетное представление.WETНебольшое повторение иногда дешевле преждевременной абстракции.SOLIDПять принципов объектного дизайна снижают связанность и стоимость изменений.Single Responsibility PrincipleМодуль должен иметь одну основную причину для изменения.Open-Closed PrincipleКомпонент расширяется без изменения стабильного кода.Liskov Substitution PrincipleПодтип должен сохранять ожидаемое поведение базового типа.Interface Segregation PrincipleКлиенты не должны зависеть от методов, которые не используют.Dependency Inversion PrincipleВысокоуровневая политика зависит от абстракций, а не деталей.Command-Query SeparationОперация либо изменяет состояние, либо возвращает данные.Tell, Don’t AskОбъекту передают намерение, а не извлекают данные для внешней логики.Law of DemeterОбъект взаимодействует только с ближайшими знакомыми объектами.High CohesionСвязанные обязанности располагаются внутри одного модуля.Low CouplingМодули минимально зависят друг от друга.Stable Dependencies PrincipleЗависимости направляются в сторону более стабильных компонентов.Stable Abstractions PrincipleСтабильные компоненты должны быть достаточно абстрактными.Common Closure PrincipleКлассы, изменяющиеся по одной причине, группируются вместе.God ObjectОдин объект концентрирует слишком много состояния и обязанностей.Shotgun SurgeryОдно изменение требует правок во множестве модулей.Feature EnvyМетод сильнее зависит от данных другого объекта, чем своего.Primitive ObsessionДоменные понятия заменяются примитивами и разрозненными проверками.Inappropriate IntimacyКомпоненты слишком глубоко знают внутренности друг друга.Divergent ChangeОдин модуль меняется по множеству несвязанных причин.Parallel Inheritance HierarchiesИзменение одной иерархии требует зеркального изменения другой.Speculative GeneralityАбстракции создаются для гипотетических будущих сценариев.Middle ManКомпонент почти полностью делегирует работу без добавления ценности.Message ChainsКлиент проходит длинную цепочку объектов ради данных или действия.Lazy ClassКласс не оправдывает стоимость собственного существования.Data ClumpsОдинаковые группы параметров повторяются и скрывают доменное понятие.Long Parameter ListМетод требует слишком много аргументов и контекста.Temporal CouplingОперации обязаны выполняться в скрытом строгом порядке.Circular DependencyКомпоненты образуют цикл зависимостей и мешают независимым изменениям.Distributed MonolithМикросервисы сохраняют жесткую связанность монолита и добавляют сеть.Shared Database Anti-PatternНесколько сервисов совместно изменяют одну схему данных.Chatty InterfaceОдна операция требует множества мелких удаленных вызовов.Golden HammerОдин знакомый инструмент применяется ко всем задачам.Architecture AstronautАбстракции становятся важнее реальной задачи и проверяемой ценности.Паттерн «Адаптер»Преобразует один интерфейс в другой, не меняя существующую реализацию.Паттерн «Фасад»Скрывает сложность подсистемы за небольшим и стабильным интерфейсом.Паттерн «Прокси»Контролирует доступ к объекту и добавляет к вызову промежуточную логику.Паттерн «Стратегия»Выносит взаимозаменяемые алгоритмы за общий контракт.Паттерн «Наблюдатель»Рассылает изменения подписчикам без жесткой связи с ними.Паттерн «Посредник»Сосредотачивает взаимодействия компонентов в отдельном координирующем объекте.Паттерн «Команда»Представляет действие как объект, который можно сохранять, повторять и отменять.Паттерн «Состояние»Меняет поведение объекта через явную модель его текущего состояния.Паттерн «Шаблонный метод»Фиксирует каркас алгоритма, оставляя отдельные шаги расширяемыми.Паттерн «Компоновщик»Позволяет одинаково работать с отдельными объектами и их деревьями.Паттерн «Декоратор»Добавляет поведение объекту через композицию, а не наследование.Паттерн Unit of WorkСобирает изменения в одну согласованную единицу фиксации.Branch by AbstractionПозволяет менять реализацию за стабильной абстракцией без долгой ветки разработки.Антикоррупционный слой DDDЗащищает модель домена от чужих терминов и ограничений интеграции.Модульный монолитСохраняет единое развертывание при строгих внутренних границах модулей.Архитектурные fitness-функцииАвтоматически проверяют, сохраняет ли система нужные архитектурные свойства.Contract TestingПроверяет совместимость взаимодействующих сервисов по согласованному контракту.Property-Based TestingГенерирует множество входов и проверяет общие свойства результата.Mutation TestingИскусственно меняет код, чтобы оценить способность тестов обнаруживать ошибки.Golden Master TestingФиксирует текущее поведение сложной системы перед безопасным рефакторингом.Test PyramidБольшинство проверок должно быть быстрым и локальным, а сквозных тестов — меньше.Test TrophyСмещает акцент к интеграционным тестам при сохранении статических и модульных проверок.Паттерн AmbassadorВыносит сетевые функции клиента в соседний прокси-процесс.Backend for FrontendСоздает отдельный серверный слой под потребности каждого типа интерфейса.Консолидация вычислительных ресурсовСовмещает несколько задач на общей инфраструктуре при контроле изоляции.Штамп развертыванияТиражирует одинаковые независимые экземпляры решения по регионам или клиентам.Внешнее хранилище конфигурацииОтделяет конфигурацию от артефакта приложения.Каналы и фильтрыРазбивает обработку на последовательность независимых этапов.Паттерн SidecarРазмещает вспомогательные функции рядом с основным приложением.