Comments 16
Шо, опять?! ©
UI может меняться (веб, консоль, мобильное приложение) без изменения бизнес-правил
А GUI (оконные приложения)? – Не, не, не слышали!
"Чистая архитектура" по идее позволяет относительно легко подключать любые ui к приложению, в т.ч. gui. Взаимодействие с gui выполняется через интерфейсы. Бизнес-логика, работа с БД вынесены в отдельные классы, поэтому смена ui ни на что не влияет (при "правильной" реализации, естественно). Возможна ли такая реализация во всех случаях - отдельный вопрос, но на небольших проектах у меня получалось подключать cli и gui через единый интерфейс.
Взаимодействие с gui выполняется через интерфейсы.
Практически, так никто не делает. Хотя я, в качестве эксперимента, пробовал этот вариант (см. мою статью: «Модульное программирование в C++. Статические и динамические плагины» в https://habr.com/ru/articles/566864/ ). Там как раз использовались интерфейсы (статические и динамические плагины) для создания GUI. Идея интересная, но народ её воспринял в штыки, поскольку это не вписывалось в парадигму: «Есть только два мнения: моё и неправильное!».
Бизнес-логика, работа с БД вынесены в отдельные классы, поэтому смена ui ни на что не влияет (при "правильной" реализации, естественно).
В своей статье: «Новая компьютерная программа для запоминания иностранных слов и фраз» ( https://habr.com/ru/articles/848836/ ) я, практически, этим и занимался.
Только я бы не сказал, что это всё просто. В данном случае, вместо «бизнес-логики» использовалась «программная логика», в качестве «БД» – «Sqlite», Для классов, главной проблемой была организация их в иерархию. Нужно было, чтобы одна база данных выдавала разные данные для шести режимов работы в разных «видах» (т.е., дочерних окнах) плюс дополнительный выбор на фильтрацию и сортировку данных, с учетом выбранных пунктов меню.
В MFC, подобная парадигма называлась «Документ-Вид», т.е., одному «окументу» (порции данных из БД) сопоставлялась несколько дочерних окон («видов»), в которых они могли быть представлены по-разному. Причем управление этими данными, осуществлялось через обработчики сообщений, которые имеют свою иерархию в циклах сообщений (от родительского окна к его потомкам). При этом, теоретическим, могут еще использоваться потоки (хотя режим «Видео», для своих данных, я реализовал с помощью таймера),
Да, MFC я не использовал из-за его трудно обходимых недостатков, а применял WTL, очень близкому к WinAPI, что не слишком упрощало разработку.
Кроме того, иерархия классов работала не только с одной БД, но и с разной графикой, различной для разных видов (графический текст, звук, фоновый изображения и логотипы, а также их корректное обновление при изменении размеров и т.п.).
Всё это, вместе, составило чрезвычайно сложный алгоритм взаимодействия разрабатываемых классов. Я себе чуть мозги не сломал, пока не добился, более-менее, приемлемого результата. Да, он не оптимальный, но, вполне рабочий. Со временем, займусь его оптимизацией и, возможно, опубликую весь код.
Поэтому, насчет «не влияет», я бы не сказал. GUI менять на UI / web / консоль и т.п., не нужно от слова «совсем». Нужно, просто добиться разной работы программной логики в разных видах (по факту, режимах работы). Эти «режимы работы» можно добавлять (в которых одни и те же порции данных из БД будут разными и отображаться по-разному в разных видах), но не более. «Кросплатформа» тоже не актуальна, тратить на нее силы не вижу смысла.
Возможна ли такая реализация во всех случаях - отдельный вопрос, но на небольших проектах у меня получалось подключать cli и gui через единый интерфейс.
Однако, «количество переходит в качество», поэтому, уже даже для «средних» проектов, вроде описанного, ситуация сильно усложняется, а концепцию «чистой архитектуры» нужно, очевидно, дополнять собственными идеями.
Независимость
Это как купить УАЗ, чтобы ездить на работу, потому что «а вдруг дорогу размоет (или снег пойдет), а я готов». В итоге 10 лет стоишь в пробке, а дороги так ни разу и не размыло.
Такой информации довольно много в открытом доступе. Было бы интереснее, если бы Вы взяли реальную компанию/бизнес, описали бы её подробно человеческим языком, а потом показали бы архитектуру для неё. Хочется больше авторства в таких статьях, а не копипаст
Не первый раз вижу эту тему, как тут все кристально, по полочкам, идеально.. но вот только начал читать, и сразу же возник вопрос: почему "посчитать процент" это метод у сущности, а "перевести деньги" - это use case? Кто определяет границу?
Чистую архитектуру уже кто только не разбирал... Например тут - https://habr.com/ru/articles/905148/
Картинка оттуда показывает, что любой hello world должен состоять минимум из 13 классов/интерфейсов. На практике мало кто так делает :) Обычно проект гвоздями прибивают ко фреймворку, интерфейсы тоже в принципе не обязательны... и т.д. И вроде нормально работает.
На мой взгляд, очень полезны следующие идеи из "чистой архитектуры": инверсия зависимостей (и всё, что говорится о зависимостях), тестируемость, слои (как хоть какая-то структура кода), и также идея о том, что "СУБД, UI, интеграции - это маловажные детали реализации, а более важен домен и его работа". Этим идеям нужно следовать в большинстве проектов, без этого даже средне-малый проект может оказаться тяжёлым для разработки.
Остальные идеи тоже хороши, но порождают переусложнение на ровном месте.
Дядя Боб взял пачку паттернов обозвал это чистой архитектурой и продал как серебряную пулю разработчикам. Правда момент, что на реалзиацию и поддержание паттернов тратится время, как-то упускается. В итоге потратили в 2 раза времени больше на разработку, зато можем безболезнено переехать с postgresql на mongodb, что по факту никогда не происходит. А если всё-таки и произойдет, то дешевле будет в моменте когда это понадобится внедрить паттерн репозитория, отрефакторить и переехать.
У меня был показательный случай когда пришел новый человек в команду и с горящими глазами мне доказывал, что надо внедрить чистую архитектуру и всё будет очень круто. В итоге он 2 дня провозился с простой задачей, пытался накрутить туда репозиторий, сам в ней утонул и попросил помочь, мы обсудили и оказалось что там буквально нужно было добавить 2-3 строчки кода: сходить в базу, обработать ответ, отдать ответ.
Брать идеи из чистой архитектуры можно и нужно, если они помогают решить какую-то проблему. Но начинать с проект с чистой архитектуры выглядит как антипаттерн - оверхэд, потому что вместо простого приложениям пишем космолёт на случай "а вдруг прилетят инопланетяне"
С одной стороны да, а с другой... У нас в компании легаси монолит, написанный людьми которые видимо про чистую архитектуру не слышали. В нем чудовищным образом переплетаются домены, сущности, которые хранят состояние и при этом используются в реквестах на любых возможных слоях кроме вьюшек. И много других приколов, из-за которых мы до сих пор хлебаем дерьмо.
А начинали наверное тоже с небольшого проекта, где нафиг не нужен был этот оверхэд.
А начинали наверное тоже с небольшого проекта, где нафиг не нужен был этот оверхэд.
А вот если бы этот небольшой проект начали сразу писать с чистой архитектуры то щас было бы всё как в сказке и не было бы проблем, угадал, да? :)
У нас в компании легаси монолит, написанный людьми которые видимо про чистую архитектуру не слышали.
Может не слышали, а может другие причины были, тем не менее проект они написали, а обесценивать и перекладывать текущие проблемы на них не айс. Вы же разрабочтики, вот и сделайте нормально теперь.
И много других приколов, из-за которых мы до сих пор хлебаем дерьмо.
Ну не хлебайте, а начинайте решать проблемы. Чистая архитектура - это набор паттернов. Не нужно тащить их все, если у вас болит только, один. Выделяете проблему, подбираете под неё паттерн и вводите его итерационно, чтобы не рефакторить весь проект. Вполне обычная история, потому что я еще не видел ни одного проекта без легаси и без проблем, потому что никакая архитектура не может предугадать как он будет развиваться, серебряной пули нет, как я уже писал.
Может и не было бы? Были бы скорее всего другие.
Естественно мы этим проблемы решаем разными способами. Но рефакторинг любой части превращается в приключение, потому что как я уже писал - в монолите крайне высокая связанность.
Если бы разработчики придерживались хотя бы некоторых принципов, типа - инверсии зависимостей. Принципов grasp , типа low coupling high cohesion. И не пользовались бы антипаттернами типа god object. Уверен, сейчас было бы на много проще рефакторить.
И возможно сейчас вместо нескольких десятков сервисов и микросервисов у нас был бы нормальный монолит ) а так в итоге почти все команды этот самый монолит покинули.
Могу предположить, что методики, подобно чистой архитектуре, являются критически важными при вайбкодинге. Применения таких методик оставляет шанс человеку не потерять контроль над архитектурой и держит LLM в рамках, ограничивая бесконтрольный рост зависимостей.
С учетом текущий тенденций, архитектурные методики могут стать ключом, а оверхед перестает быть сколько-нибудь значимым фактором.
Чистая архитектура