Это то, что мы видели и слышали много. Многие из нас это обсуждали, а некоторые даже применяли на практике. Мы знаем, как, но знаем ли мы также и о том, ПОЧЕМУ?
Здесь мы пытаемся ответить на вопросы «почему» чистой архитектуры.
Почему график выглядит именно так?
Разве порядок операций не должен быть следующим: «Логика представления» > «Логика бизнеса» > «Логика данных» (БД) и наоборот?
Да вы правы; однако то, что мы видим здесь, является правилом зависимости. Поток по-прежнему пользовательский интерфейс › Бизнес-логика › Логика данных (БД). Согласно этому правилу, зависимости могут указывать только внутрь. Внутренний круг не должен полагаться на внешние круги и не должен ничему у них учиться.
Почему мы должны следовать правилу зависимости?
Существует множество архитектур, но у большинства из них есть одна общая цель: разделение задач.
Определение того, какой уровень может и должен быть независимым, сделает ваш код легким в обслуживании и упростит тестирование.
Например, простая система входа. Принятие имени пользователя и пароля, их проверка и возврат значения true (если он действителен) или false (если он недействителен) — основные этапы процесса входа в систему. Как видно из основного бизнес-процесса, он ничего общего с пользовательским интерфейсом (UI), используемой базой данных или способом ввода имени пользователя и пароля (текстовое поле, распознавание голоса, мобильный телефон, Интернет и т. д.).
Почему его легко поддерживать?
- Измените, как система принимает имя пользователя и пароль (через текстовое поле, распознавание голоса и т. д.), не затрагивая бизнес-уровень и уровень данных.
- Обновите используемую базу данных (или API), не затрагивая презентационный и бизнес-уровень.
- Легко обновляйте внешние слои, не слишком беспокоясь о внутренних слоях.
Почему тестировать легко?
- Создание модульных тестов на любом слое без создания ненужных зависимостей.
- Зависимость инвертирована, что означает, что легко передать фиктивную зависимость для слоя, который нам нужно протестировать.
Зачем нам писать тесты?
Я написал об этом статью: https://medium.com/@tentenponce/part-1-writing-tests-f2a46569f583
Почему Почему?
Существует много способов настроить чистую архитектуру, но если мы поймем саму чистую архитектуру, мы обнаружим, что все они одинаковы и следуют одним и тем же принципам.
Вместо того, чтобы слепо следовать шаблону, лучше понять причину, по которой мы это делаем, так как это поможет нам определить, какое решение следует использовать в зависимости от наших проблем. Помните, что разные проблемы требуют разных подходящих решений, и для любой проблемы не существует универсального решения.
Знание причин архитектуры, шаблонов проектирования, лучших практик, стандартов и принципов кодирования поможет нам стать лучшими программистами.
Последние мысли
- Чистая архитектура сама по себе должна быть простой для понимания, поскольку она основана только на правиле зависимостей.
- Шаблон проектирования отличается от чистой архитектуры, мы все еще можем ошибаться в чистой архитектуре, даже если следуем шаблону проектирования.
- Что делает чистую архитектуру сложной задачей? Я не считаю, что его сложно освоить, но сложно оценить его достоинства/выгоды: ремонтопригодность и легкость тестирования. Почему? Потому что мы не занимаемся обслуживанием с самого начала, а модульное тестирование не влияет непосредственно на фактический результат нашего приложения.
Не стесняйтесь комментировать что-либо и не стесняйтесь указать, если вы обнаружите что-то не так. Давайте все стремиться стать лучшим программистом.
