Comments 21
А разве "компоненты" были ещё не в Delphi? Класс TComponent и всё такое. Даже плевались потом, говорили, мол, компоненты плодят антипаттерны. Или сейчас другие компоненты?
А можете про антипаттерны в двух словах?
Аж в Википедии увековечено: 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 это написание прикладной логики в обработчиках нажатий на кнопку"
Ээээммм… Я про
говорили, мол, компоненты плодят антипаттерны
Всё верно. В дельфи кнопка — это компонент класса TButton, унаследованный от TComponent
Мой комментарий был про то, что термин "компонент" немножко более древний и что люди употребляли термин "компонент" задолго до 2016 года
Вы по-прежнему не объяснили, почему компоненты плодят антипаттерны
С другой стороны, по мере усложнения продукта и увеличения команд над ним работающих (а кажется что все к этому идет), наоборот, ограничения в технологиях может стать критичным фактором.
Тут наверное стоит упомянуть закон Конвея, сформулированный в 1967году:
«Организации, проектирующие системы, … производят их, копируя структуры коммуникации, сложившиеся в этих организациях»
Плюс дополнительное обслуживание механизма «дружбы» всех этих модулей.
Ваш подход может быть оправдан, когда модули между собой не связаны, например бэк-энд и фронт-энд на разных клиентских фреймворках могут работать.
И я даже не буду сейчас расписывать риски связанные с миграцией разработчиков с одновременным разрастанием зоопарка.
Взгляд с моей колокольни:
Application (конечное приложение) – набор html/js/css, который отображается пользователю. Конечное приложение может в общем случае не использовать принципы Modular JavaScript и быть написано на любом языке, хоть на flash.
Приложение — такой же компонент, как и остальные, только больше.
Application Controller – JS-объект, реализующий принципы Modular JavaScript, позволяющий модулям общаться и встраиваться рядом и друг с другом.
Для любого компонента контроллером является его владелец — компонент выше по иерархии.
Module – JS-приложение на любом языке, подобном JS.
Модуль — набор файлов на разных языках, даже не подобных JS
Sandbox – объект, через который Module может общаться с внешним миром.
Компонент не общается с внешним миром, а если и общается, его владелец легко может завернуть общение на себя.
BroadcastService – сервис, позволяющий модулям общаться.
Скажем нет этому клубку ниток. Владелец нескольких компонент полностью контролирует коммуникации его подопечных.
Модуль может вызывать только свои методы или методы Sandbox.
Модуль может вызывать только свои методы и ничего не знать о внешнем мире.
Если модулю что-нибудь нужно, это нужно спросить у Sandbox.
Если модулю что-то нужно — пусть сам себе это и создаст. Кому не понравится поведение по умолчанию — переопределит.
Не разбрасывать игрушки (модуль не должен создавать глобальные переменные).
Все имена в нелокальных пространствах мён должны иметь префикс с именем модуля.
1. разбить на шаги, каждый из которых это atomic message.
Начал проводить платеж, снял деньги с одного, записал состояние в очередь из которой два выхода — снял со второго и закомитил либо не получилось и сложил новое событие на возврат денег первому.
Этакий конечный автомат и по сути ручная многоступенчатая транзакция на бизнес логике. Иногда без этого никак если между шагами 1 и два есть например внешний сервис (допустим надо провести проверку на мошенничество, которая может занять время). А деньги снимаются, чтобы параллельный перевод не схватил.
2. логическое укрупнение сервисов, чтобы транзакция целиком проходила внутри сервиса.
Получается довольно редко, но иногда прокатывает если удается по бизнес логике.
3. распределенная транзакция.
Это может быть как двухфазный коммит (условно если разные базы) или передача transactionId как параметра.
Вытащить отдельно кучу интеграций — когда надо данные залить в систему извне или вылить наружу.
Монолит прилично урежется, останется один (ну или небольшое количество если удачно поделите) большой сервис который транзакционный.
Будет пачка микро и один макро сервис уже позитив. Время деплоя меньше, части менее зависимы. Хотя оркестрация тоже геморрой.
https://www.infoq.com/articles/microservices-aggregates-events-cqrs-part-1-richardson
Если кратко:
— кластер доменов это агрегат (микромонолит). Внутри агрегата обычные транзакциями.
— приложение строится на CQRS + EventSourcing принципах
— консистентность между сервисами обеспечивается на уровне обмена сообщениями. Т.е. глобальной консистентноости нет, но каждый микросервис в отдельный момент времени находится в консистентном состоянии
— в статье не указано, но на практике это важно. Повторная отправка + идемпотентность для сообщений
Выбранный UI-фреймворк – вред. Архитектурные требования – профит