Clean Architecture (Чистая архитектура) (Рубрика Architecture)

Я прочитал эту книгу Дяди Боба (Роберта С. Мартина) шесть-семь лет назад и нашел концепции достаточно интересными, а по самым интересным частям я даже сделал подробные разборы: "Дизайн и архитектура, парадигмы программирования" и "Принципы дизайна модулей и разделения по компонентам", но все это было до старта этого канала. Поэтому сегодня я решил исправить это недоразумение и рассказать об этой книге, в которой Дядя Боб подчеркивает важность разделения ответственности и независимость от фреймворков, баз данных и пользовательских интерфейсов. Дядя Боб это делает очень ультимативно, что сильно подрывает веру в его подход. Ключевыми идеями являются следующие Правило зависимостей: зависимости исходного кода должны указывать только внутрь, в направлении высокоуровневых политик. Это создает систему, в которой бизнес-правила не зависят от технических деталей. Слоеность архитектуры: при реализации этого правила у нас появляются отдельные слои - Entities (cущности) - основные бизнес-объекты и корпоративные бизнес-правила - Use cases (варианты использования) - бизнес-правила конкретного приложения. Тут забавно, что этот термин взят из UML, где так называется один из видов диаграмм, про которые я рассказывал раньше

• Interface adapters (адаптеры интерфейса) - контроллеры, презентеры и шлюзы
• Framework & drivers (фреймворки и драйверы) - внешние инструменты, базы данных, UI-фреймворки Этот архитектурный подход близок к гексагональной архитектуре (hexagonal architecture) или порты и адаптеры и луковая архитектура (onion architecture). Она также активно включает принципы SOLID, особенно принцип инверсии зависимостей, на котором строится вся слоистость и правило зависимостей. Боб говорит о том, что архитектура должна "кричать" о своем назначении — при взгляде на структуру кодовой базы она должна отражать бизнес-домен, а не технические детали.

С точки зрения применимости clean architecture наиболее полезна в следующих сценариях:

• Сложные или долгоживущие приложения, где поддерживаемость является критически важной
• Системы, где доменную модель решили выделить отдельно и использовать стиль DDD (domain driven design)
• Проекты, требующие четкого разделения между бизнес-логикой и инфраструктурой Она помогает создавать системы, которые могут развиваться со временем в соответствии с изменяющимися бизнес-потребностями, и обеспечивает гибкость для замены фреймворков, баз данных или UI-технологий с минимальным влиянием на основную бизнес-логику.

Но этот подход заслуженно критикуют за

• Избыточную сложность для малых или простых проектов с прямолинейными требованиями
• Чрезмерную слоистость и натыкивание интерфейсов без явных преимуществ, что приводит к "злоупотреблению интерфейсами"
• Избыточный шаблонный код и абстракции, которые затрудняют понимание системы
• Чрезмерно крутую кривую обучения для инженеров и строгую дисциплину для правильной реализации
• Замедление начального развития проекта из-за предварительных усилий по проектированию
• Низкую производительность итогового решения из-за чрезмерного количества абстракций

Итого, я видел подходы к применению Clean Architecture для повышения качества кода в существующих проектах, но я уже активно не писал код сам, когда Uncle Bob явил свою концепцию миру. Именно поэтому я не могу оценить из первых рук насколько с ней получаются хорошие приложения:) Но мне кажется, что это как с любым подходом - можно сделать хорошо, а можно тяп-ляп ... Чистая архитектура тут не исключение.

#Architecture #Software #Engineering #DistributedSystems #SystemDesign