Чистая архитектура

[jlllk]

Шо, опять?! ©

[Emelian]

UI может меняться (веб, консоль, мобильное приложение) без изменения бизнес-правил

А GUI (оконные приложения)? – Не, не, не слышали!

[Akon32]

"Чистая архитектура" по идее позволяет относительно легко подключать любые ui к приложению, в т.ч. gui. Взаимодействие с gui выполняется через интерфейсы. Бизнес-логика, работа с БД вынесены в отдельные классы, поэтому смена ui ни на что не влияет (при "правильной" реализации, естественно). Возможна ли такая реализация во всех случаях - отдельный вопрос, но на небольших проектах у меня получалось подключать cli и gui через единый интерфейс.

[Emelian]

Взаимодействие с 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 через единый интерфейс.

Однако, «количество переходит в качество», поэтому, уже даже для «средних» проектов, вроде описанного, ситуация сильно усложняется, а концепцию «чистой архитектуры» нужно, очевидно, дополнять собственными идеями.

[errorcost]

Независимость

Это как купить УАЗ, чтобы ездить на работу, потому что «а вдруг дорогу размоет (или снег пойдет), а я готов». В итоге 10 лет стоишь в пробке, а дороги так ни разу и не размыло.

[Stanislav_Z]

Такой информации довольно много в открытом доступе. Было бы интереснее, если бы Вы взяли реальную компанию/бизнес, описали бы её подробно человеческим языком, а потом показали бы архитектуру для неё. Хочется больше авторства в таких статьях, а не копипаст

[Akon32]

Боюсь, такое обычно под NDA... Впрочем, можно попробовать соорудить pet project, но эта "чистая архитектура" не слишком приятна при реализации.

[mityukov]

Не первый раз вижу эту тему, как тут все кристально, по полочкам, идеально.. но вот только начал читать, и сразу же возник вопрос: почему "посчитать процент" это метод у сущности, а "перевести деньги" - это use case? Кто определяет границу?

[Akon32]

Чистую архитектуру уже кто только не разбирал... Например тут - https://habr.com/ru/articles/905148/

как правильно сами знаете что

Картинка оттуда показывает, что любой hello world должен состоять минимум из 13 классов/интерфейсов. На практике мало кто так делает :) Обычно проект гвоздями прибивают ко фреймворку, интерфейсы тоже в принципе не обязательны... и т.д. И вроде нормально работает.

На мой взгляд, очень полезны следующие идеи из "чистой архитектуры": инверсия зависимостей (и всё, что говорится о зависимостях), тестируемость, слои (как хоть какая-то структура кода), и также идея о том, что "СУБД, UI, интеграции - это маловажные детали реализации, а более важен домен и его работа". Этим идеям нужно следовать в большинстве проектов, без этого даже средне-малый проект может оказаться тяжёлым для разработки.

Остальные идеи тоже хороши, но порождают переусложнение на ровном месте.

[kalombo]

Дядя Боб взял пачку паттернов обозвал это чистой архитектурой и продал как серебряную пулю разработчикам. Правда момент, что на реалзиацию и поддержание паттернов тратится время, как-то упускается. В итоге потратили в 2 раза времени больше на разработку, зато можем безболезнено переехать с postgresql на mongodb, что по факту никогда не происходит. А если всё-таки и произойдет, то дешевле будет в моменте когда это понадобится внедрить паттерн репозитория, отрефакторить и переехать.

У меня был показательный случай когда пришел новый человек в команду и с горящими глазами мне доказывал, что надо внедрить чистую архитектуру и всё будет очень круто. В итоге он 2 дня провозился с простой задачей, пытался накрутить туда репозиторий, сам в ней утонул и попросил помочь, мы обсудили и оказалось что там буквально нужно было добавить 2-3 строчки кода: сходить в базу, обработать ответ, отдать ответ.

Брать идеи из чистой архитектуры можно и нужно, если они помогают решить какую-то проблему. Но начинать с проект с чистой архитектуры выглядит как антипаттерн - оверхэд, потому что вместо простого приложениям пишем космолёт на случай "а вдруг прилетят инопланетяне"