[1/2] Сложность и модулярность две стороны одной медали - Влад Хононов - ArchDays 2023 (Рубрика Architecture)
Интересное выступление Влада Хононова с конференции по архитектуре, в программный комитет которой я состою. В этом выступлении Влад рассказал кратко связь complexity и modularity, которые позволяют ввести интересные метрики качества систем и кода, которые упрощают coupling/connascence/cohesion. Этот доклад основан на материале книги "Balancing Coupling in Software Design", которую я закажу в бумаге сразу после ее издания
Ну а теперь пройдемся по основным мыслям доклада
- Влад определяет систему как набор взаимосвязанных элементов, организованных для достижения цели (это основано на определении Медоуз из книги "Азбука системного мышления", про которую я уже рассказывал)
- Дальше автор идет вглубь уровней абстракций и показывает, что система - это фрактальная история вида: системы -> микросервисы -> неймспейсы -> классы -> методы -> ...
- Возникает вопрос, а в чем разница между компонентами системы и модулем? И автор показывает, что различие не в физических или логических границах. Автор обращается к классическим определением модулей (self-contained, вызывается другими элментами, может быть скомпилированными отдельно). И дальше автор говорит, что у компонентов и модулей отличие в целях - деление на компоненты решает текущую задачу системы, а деление на модули помогает решить будущую задачу, когда система будет эволюционировать.
- Потом автор рассказывает про определение сложности от автора фреймворка Cynefin, где сложность зависит от простоты установления связи между причиной и эффектом. Условно, если мы можем предсказать последствия своих действий в системе, то это простая система. А вот если нам нужны эксперименты для определения взаимосвязи, то комплексная система
- В проектировании софта сложность может быть локальной и глобальной (условно сложность внутри модуля или сложность взаимосвязей между модулями). Понятно, что локальность/глобальность сложности зависит от точки
- В итоге, модульность и сложность - многоуровневые явления, которые можно наблюдать на разных уровнях абстракций.
- Дальше автор показывает метрики сложности, которые приводил uncle Bob в своей книге "Clean Architecture". Кстати, я уже делал краткое саммари ее части про дизайн модулей здесь. Влад в выступлении показывает как можно хачить метрики abstractness, stability, distance from main sequence. Хотя при желании можно похачить любые метрики, а значит и метрики самого Влада, которые он предлагает дальше:)
- Влад предлагает метод оценки через модель интеграции, которая основана на оценке взаимосвязи между элементами системы. Эта модель объединяет coupling/connascence/cohesion. Суть в том, что нам надо оценить интенсивность обмена между модуля по этим связям
- Модель включает четыре уровня, которые идут от самых терминальных случаев к оптимальным (по мере этого уменьшается объем общих знаний между модулями)
- Intrusive coupling - интеграция через вторжение, когда нарушаются границы инкапсуляции и зависимый модуль получает доступ к внутренней реализации другого модуля. Примеры: взаимодействие через базу данных, использование reflection для доступа к приватным свойствам.
- Functional coupling - взаимосвязь через функцию или бизнес-требования. Интересно, что тут не обязательно наличие связи в коде.
- Model coupling - связь через общую модель бизнес домена, структуру данных. Здесь нам дальше сложно эволюционировать общую модель
- Contract coupling - связь через контракты (API). В DDD для этого есть способы вида published language, anti-corruption layer, etc
Про то, как использовать эту модель я расскаал в продолжении поста, плюс рекомендую другую книгу Влада "Learning DDD" ("Изучаем DDD – предметно-ориентированное проектирование"), про которую я много рассказывал раньше.
#Software #Architect #SystemDesign #SoftwareArchitecture #Processes #Management