Выбранный UI-фреймворк – вред. Архитектурные требования – профит

[spmbt]

Вы как-то подотстали в своём развитии от 2016-го года. У вас нет нового ключевого слова «компонент», хотя в пункте 7 и в углу картинки вы жестами его изобразили. Кто не произносит этого слова, таких даже не берут в космонавты. На что вы рассчитывали, выходя в тусовку в разгаре 2017-го и не произнося «компоненты»?

[homecreate]

А разве "компоненты" были ещё не в Delphi? Класс TComponent и всё такое. Даже плевались потом, говорили, мол, компоненты плодят антипаттерны. Или сейчас другие компоненты?

[raveclassic]

А можете про антипаттерны в двух словах?

[homecreate]

Аж в Википедии увековечено: https://ru.m.wikipedia.org/wiki/%D0%90%D0%BD%D1%82%D0%B8%D0%BF%D0%B0%D1%82%D1%82%D0%B5%D1%80%D0%BD

"Волшебная кнопка (Magic pushbutton): Выполнение результатов действий пользователя в виде неподходящего (недостаточно абстрактного) интерфейса. Например, в системах типа Delphi это написание прикладной логики в обработчиках нажатий на кнопку"

[raveclassic]

Ээээммм… Я про

говорили, мол, компоненты плодят антипаттерны

[homecreate]

Всё верно. В дельфи кнопка — это компонент класса TButton, унаследованный от TComponent

Мой комментарий был про то, что термин "компонент" немножко более древний и что люди употребляли термин "компонент" задолго до 2016 года

[raveclassic]

Вы по-прежнему не объяснили, почему компоненты плодят антипаттерны

[homecreate]

«Компонент» в понимании Delphi поощряет написание кода в формате «волшебная кнопка», размазывая бизнес-логику по обработчикам событий компонентов вместо того, чтобы собирать её в одном классе/модуле. Что имел в виду под компонентом товарищ spmbt, я не знаю, ещё раз повторюсь, что хотел указать лишь на возраст термина

[habradante]

Для удовлетворения хотелок фронт-энд разработчиков пощупать разные фреймворки, такая архитектура хороша, наверное. Но с точки зрения бизнеса это лишь усложняет поддержку. Да и непонятно зачем зоопарк фреймворков на клиенте. Придумывать и реализовывать архитектуру ради того чтобы поиграть с ангуларом и реактом одновременно… зачем?

[dnovozhilov]

Вы правы, это не везде применимо. В простых проектах такая архитектура приносит больше сложностей, чем профита.

С другой стороны, по мере усложнения продукта и увеличения команд над ним работающих (а кажется что все к этому идет), наоборот, ограничения в технологиях может стать критичным фактором.

Тут наверное стоит упомянуть закон Конвея, сформулированный в 1967году:
«Организации, проектирующие системы, … производят их, копируя структуры коммуникации, сложившиеся в этих организациях»

[habradante]

По моему опыту, в больших проектах это приносит еще больше сложностей, чем в простых. Даже банально исправление багов в разных частях такого продукта придется поручать разным людям. Либо человеку придется изучать несколько фреймворков и переключать мозг между ними довольно быстро, если баг затрагивает несколько модулей, либо нужно поправить несколько багов.
Плюс дополнительное обслуживание механизма «дружбы» всех этих модулей.
Ваш подход может быть оправдан, когда модули между собой не связаны, например бэк-энд и фронт-энд на разных клиентских фреймворках могут работать.
И я даже не буду сейчас расписывать риски связанные с миграцией разработчиков с одновременным разрастанием зоопарка.

[dnovozhilov]

Берите команду еще больше ;)
Нет таких кейсов:
— исправление багов в разных частях такого продукта придется поручать разным людям
— миграцией разработчиков.

Это разные команды, у каждого своя часть предметной области, свои лидеры и свои технологии.
А для конечного пользователя продукт один.

[ertaquo]

Ох уж эти хипстерские технологии. Там, где можно написать три строчки, они развернут целую философию (которую никто не поймет, включая их самих), и напишут три сотни (размазав по десятку файлов).

[webdiez]

[vintage]

Взгляд с моей колокольни:

Application (конечное приложение) – набор html/js/css, который отображается пользователю. Конечное приложение может в общем случае не использовать принципы Modular JavaScript и быть написано на любом языке, хоть на flash.

Приложение — такой же компонент, как и остальные, только больше.

Application Controller – JS-объект, реализующий принципы Modular JavaScript, позволяющий модулям общаться и встраиваться рядом и друг с другом.

Для любого компонента контроллером является его владелец — компонент выше по иерархии.

Module – JS-приложение на любом языке, подобном JS.

Модуль — набор файлов на разных языках, даже не подобных JS

Sandbox – объект, через который Module может общаться с внешним миром.

Компонент не общается с внешним миром, а если и общается, его владелец легко может завернуть общение на себя.

BroadcastService – сервис, позволяющий модулям общаться.

Скажем нет этому клубку ниток. Владелец нескольких компонент полностью контролирует коммуникации его подопечных.

Модуль может вызывать только свои методы или методы Sandbox.

Модуль может вызывать только свои методы и ничего не знать о внешнем мире.

Если модулю что-нибудь нужно, это нужно спросить у Sandbox.

Если модулю что-то нужно — пусть сам себе это и создаст. Кому не понравится поведение по умолчанию — переопределит.

Не разбрасывать игрушки (модуль не должен создавать глобальные переменные).

Все имена в нелокальных пространствах мён должны иметь префикс с именем модуля.

[bano-notit]

Кх кх, здравствуйте)

[robert_ayrapetyan]

Расскажите, как у вас реализована транзакционность между микросервисами

[StanislavL]

Я не автор, но могу описать некоторые из подходов.
1. разбить на шаги, каждый из которых это atomic message.
Начал проводить платеж, снял деньги с одного, записал состояние в очередь из которой два выхода — снял со второго и закомитил либо не получилось и сложил новое событие на возврат денег первому.
Этакий конечный автомат и по сути ручная многоступенчатая транзакция на бизнес логике. Иногда без этого никак если между шагами 1 и два есть например внешний сервис (допустим надо провести проверку на мошенничество, которая может занять время). А деньги снимаются, чтобы параллельный перевод не схватил.
2. логическое укрупнение сервисов, чтобы транзакция целиком проходила внутри сервиса.
Получается довольно редко, но иногда прокатывает если удается по бизнес логике.
3. распределенная транзакция.
Это может быть как двухфазный коммит (условно если разные базы) или передача transactionId как параметра.

[robert_ayrapetyan]

Хм, понятно, спасибо. Вообщем все очень плохо. Для меня это единственный фатальный недостаток, когда заходит речь о переезде бизнес-логики на микросервисную архитектуру в большом проекте.

[StanislavL]

Можно в микросервисы вынести части которые не требуют ACID — отчеты там и отображения, куча всего связанного с UI, логами и т.п.
Вытащить отдельно кучу интеграций — когда надо данные залить в систему извне или вылить наружу.
Монолит прилично урежется, останется один (ну или небольшое количество если удачно поделите) большой сервис который транзакционный.
Будет пачка микро и один макро сервис уже позитив. Время деплоя меньше, части менее зависимы. Хотя оркестрация тоже геморрой.

[1goblin]

Лучшее (но не идеальное) решение этой проблемы я встретил в статье
https://www.infoq.com/articles/microservices-aggregates-events-cqrs-part-1-richardson

Если кратко:
— кластер доменов это агрегат (микромонолит). Внутри агрегата обычные транзакциями.
— приложение строится на CQRS + EventSourcing принципах
— консистентность между сервисами обеспечивается на уровне обмена сообщениями. Т.е. глобальной консистентноости нет, но каждый микросервис в отдельный момент времени находится в консистентном состоянии
— в статье не указано, но на практике это важно. Повторная отправка + идемпотентность для сообщений