Доклад посвящен:
- Пользовательским интерфейсам ориентированным на задачи (Task Based UI)
- CQRS (Command/Query Responsibility Segregation)
- Микросервисы
- Закон Конвея и его влияние на примере организации команд в Magento
- Fine-grained сервисы vs Coarse-grained сервисы
- Синхронность vs Асинхронность
- Модель Акторов (Actor Model)
Вторая часть доклада находится под хабракатом.
Комментарии (32)
Shtucer
01.08.2017 09:55+2Почему "Актер"?
Szer
01.08.2017 10:01Поддержу вопрос и напомню, что термин актор (ударение на первый слог) существует в математической и компьютерной теории с 1973 года.
Shtucer
01.08.2017 11:19Теперь бы еще в видео исправить....
maghamed
01.08.2017 11:30Я не читал ничего по данной тематике на русском языке, и не знаю корректных переводов определённых терминов (i.e. coarse grained service) потому что привык говорить их по-английски. Этот доклад был рассчитан на англо говорящую аудиторию, и ей он и презентовался. Запись на видео — dev talk внутри компании после конференции.
Жаль, что у вас нет замечаний по сути, Вы очень упорный могла бы получиться интересная дискуссия. А так обсуждаем некорректный перевод уже который комментарий.
Кстати, всегда думал, что на Хабре хорошим тоном принято считать уведомление автора статьи об ошибках в личном сообщении.Shtucer
01.08.2017 11:49Что вы сразу обижаться-то? Я спросил здесь лишь потому, что вы это слово используете и в видео и в тексте. Это могло оказаться что-то новое, отличное от Модели Акторов, о чем я, а может и многие, не слыхали до этого. А если это и ошибка, на видео этого не исправить уже. А так теперь всем ясно, что вы конкретно имели в виду.
ilivit
01.08.2017 12:53+1На сколько я смог понять в REST в uri не должны использоваться глаголы, а действие описывается методом запроса (GET, POST и т.д.). У вас же, в Commanding API в конце uri стоят команды (activate, describe). На сколько это критично или (не)правильно с точки зрения REST? Или это не настолько критично в архитектуре приложения?
maghamed
01.08.2017 13:27+1Основная идея в том, что REST зачастую используют для CRUD операций, поэтому API выглядят как
действие, которые определяется HTTP Request методом (POST, GET, PUT, DELETE, PATCH и т.д.) и путь к сущности над которой совершается действие.
Например,
PUT /products/{id} - редактировать продукт POST /products - создать продукт
В случае Task Based UI и CQRS — мы всегда создаем команды для выполнения, т.е. у нас по факту получается для
Query операций используется GET метод и для Command операций используется всегда POST метод (т.к. мы создаем команду в идеологии REST для этого используется POST). Остальные методы нам по сути не нужны.
За счет этого мы уходим от концепции CRUD, которая в основном удобна при RAD (Rapid application development), когда мы хотим быстро развернуть приложение и сложность этого приложения не велика, таким образом сущности и их API зачастую представляют собой отображение того как эти сущности хранятся в базе. И переходим ближе к Domain Driven API (Проблемно-ориентированные API), которые лучше отражают бизнес процессы, происходящие в системе.
Собственно этот слайд показывал как меняется REST API с переходом на CQRS
boblgum
01.08.2017 19:40-1Вот как раз это создаем команду и резануло по уху.
ИМХО, ну или как я понимаю CQRS, с точки зрения клиента к REST добавляется возможность конкретизировать функционал. В том смысле, что клиент все еще работает с определенным ресурсом. поэтому в вашем примере я бы все таки сделал PUT.
Сам глагол уже является командой. То есть ничего создавать не надо. На сервере из "разбитых" данных реквеста собирается объект, с которым domain может работать. Но это всего лишь трансформирование.maghamed
01.08.2017 20:00честно-говоря, по вашему описанию я смутно понял, что вас резануло по уху.
Но в CQRS особенно в сочетации с Event Sourcing, команды именно создаются после выполнения какого-либо действия.
Действие порождает создание команды, которая ложится в очередь команд на обработку. И будет обработана вне основного потока выполнения программы.
Так как сама природа CQRS + Event Sourcing — это Eventual Consitency
ACID (Atomicity, Consistency, Isolation, Durability) заменяется на -> BASE (Basically Available, Soft state, Eventual consistency).
Если я вас понял правильно, то
Вы продолжаете рассуждать с точки зрения работы с ресурсом и его модицикации (т.е. вы рассуждаете в стиле CRUD). Например, чтобы пометить продукт как Out of Stock вы делаете следующие шаги
- достали продукт по айдишнику
- изменили статус продукту
- сохранили продукт
но бизнес процессы у вас другие. Для человека из бизнеса есть операция — вывести продукт из стока:
- вывести продукт из стока — для этого действия создается операция
Создавая такие API, которые соответсвуют ubiquitous language (в терминологии Эванса) вы гораздо точней описываете доменную область и процессы в ней.
boblgum
01.08.2017 21:02честно-говоря, по вашему описанию я смутно понял, что вас резануло по уху.
То, что вы обосновываете использование POST тем, что при запросе
POST /product/{id}/activate
вы создаете команду.
Таким образом вы как бы говорите юзеру, что он мол теперь будет создавать команды, а не работать с ресурсами.
Мое понимание CQRS: юзер говорит вам конкретно, что он хочет сделать с ресурсом. Он не создает, а посылает готовые команды.
С точки зрения бизнеса юзер все еще работает с ресурсом (product)
С точки зрения бизнеса юзер всего навсего хочет изменить ресурс (activate)
Ну а насчет Event Sourcing это уже другая тема :)
maghamed
01.08.2017 21:50+1теперь будет создавать команды, а не работать с ресурсами.
Да, вы правильно поняли, именно это и есть принципиальное отличие двух подходов.
Вы просто уже привыкли думать по CRUD-у так как в основном именно так писали, поэтому он вам кажется более логичным.
Смотрите, есть такой набор API
в CRUD API у вас все крутится вокруг ресурса. И ваши API — это фактически аксессоры которые меняют какие-то из полей этого ресурса (изменяют его состояние).
И если в случае изменения статуса или уценки продукта вам все еще кажется, что это просто изменения состояния ресурса, хотя на самом деле это бизнес операция, которая влечет за собой изменение состояния.
То в случае операции заказа продукта (Place Order) — у вас нет ресурса заказ в системе, чье состояние вы могли бы изменить. Это бизнес операция, которая повлечет за собой изменения ряда сущностей.
Здесь, кстати, очень показательный момент
юзер говорит вам конкретно, что он хочет сделать с ресурсом.
Вы как программист привыкли следить за состоянием сущностей и их переходом из одного в другое. Во время отладки, при дебаге и т.д.
На самом деле в ООП сущности меняют свое состояние исключительно как side-effect выполнения каккой-то команды. Основный принцип ООП — tell don't ask .
Поэтому у вас не может быть просто изменения статуса (Out of Stock) — у вас есть команда, которая создали и которую нужно обработать.
Поэтому юзер никогда не скажет, что он хочет сделать с ресурсом, юзер просто скажет — что он хочет сделать , для него это первично. Не ресурс, а операция.
boblgum
03.08.2017 09:34+1Давайте мы сначала условимся, что не будем делать выводы о том как кто думает или к чему мы привыкли. В течение последних лет 5-6 я думаю, что успел отвыкнуть от CRUD так как полностью перешел на CQRS.
Так же попробуем обозначиться с тем, что же на самом деле CRUD и чем он отличается от CQRS.
CRUD и CQRS всего лишь разный подход к организации и уровень инкапсуляции кода. Буква S из SOLID.
- CRUD — разделение на уровне методов
- CQRS — разделение на уровне классов
Исходя из это следует, что CQRS — логическое расширение возможностей CRUD-а. В свою очередь это расширение обосновано недостаточностью CRUD-а с точки зрения бизнеса. Я с вами согласен, что бизнес чаще требует функционал который не умещается в рамки прямой обработки ресурсов. Чаще бизнес требует некоей комбинации. Это конечно если мы не собираем phpMyAdmin.
Далее к тому, что и где создается. Забудем и уберем в сторону Event Sourcing (пока что).
команды именно создаются после выполнения какого-либо действия
Нет. Команды определяют действия. Набор команд есть тот функционал, который ваша система способна отработать. Нет команды — нет процесса. Набор команд как раз и есть тот API через который клиент может общаться с вашей системой.
В CRUD-е этот функционал жестко ограничен самим наименованием принципа. Переход с CRUD-а на CQRS делает возможным приблизить описание API к реальности бизнеса.
Вы продолжаете рассуждать с точки зрения работы с ресурсом
Не я, а вы. Это пример из вашего доклада. Вы попытались на этом примере показать различия. И с точки зрения пользователя вашим сервисом они у вас отличаются в следующем
- из всех глаголов HTTP используются только два
- добавляем свои глаголы
Зачем вам вообще тогда HTTP-глаголы? Ваша система от них не зависит ни коим образом, так как каждый вами придуманный глагол определяет функционал системы.
[irony] Добавьте к URL изменения сущности 'update' и не мучайтесь с HTTP вообще [/irony]
И ваши API — это фактически аксессоры которые меняют какие-то из полей этого ресурса
И опять, не мои, а как раз ваши. Это ваш Commanding API
POST /product/{id}/order
Если уж вы решили показать CQRS то должно быть что-то типа
POST /place-order { "payment": { ... }, "items": [ { "count": 5, "product_id": 5 } ] }
Поэтому юзер никогда не скажет, что он хочет сделать с ресурсом, юзер просто скажет — что он хочет сделать, для него это первично. Не ресурс, а операция.
Верно, но не всегда. После
place-orderюзер вполне может проявить желание изменить заказ. И, если конечно позволяет бизнес, тут вполне можно обойтись CRUD-ом. Так как конечный результатplace-orderкак раз и есть созданый вашей системой новый ресурс —Order. Так как это и есть те ресурсы которые ваш бизнес стремится скрафтить. Это основание вашего бизнеса — создание и обработка заказовOrder.
Таким образом приходим к следующему. Посредством CQRS мы описываем API системы. При этом мы конкретизируем и запаковываем процессы бизнеса. Но чтобы запустить такой процесс системе нужна соответствующая команда. С этой командой юзер передает данные нужные для процесса.
Request -> transfort to Command -> Command -> handle Command -> [.. BUSINESS ..] -> Order
А вот теперь вернемся к Event Sourcing. При чем тут CQRS вообще? Что это вообще?
Capture all changes to an application state as a sequence of events.
[https://martinfowler.com/eaaDev/EventSourcing.html]Тут вообще ни слова про команды.
Весь фокус в том, как наш бизнес воспринимаем ресурсы и состояние системы. В классическом варианте послеplace orderнаш бизнес ожидает и требуетOrderкак результат. При этом теряя возможность отслеживать изменения ресурса во времени. Тут, если надо, на помощь приходит Event Sourcing. Дальше углубляться не буду.
Исходя из этого мы опять приходим к тому, что система не создает команды. В процессе обработки команды создаются сообщения
Event. И вот они уже ложатся в очередь на обработку. При обработке такого сообщения можно запускать соответствующие суб-бизнес-процессы посредством команд. В противном случае это надо было бы назвать Command (Query) Sourcing.
handle Command -> dispatch(RemoveProductFromStockEvent($command->getProduct(), $command->getCount())) -> dispatch(PreparePackaging(new Unit::Kilo($command->getWeight())))
ну, вот как-то так.
maghamed
03.08.2017 10:58+1Так же попробуем обозначиться с тем, что же на самом деле CRUD и чем он отличается от CQRS.
Нет, я на этом этапе с вами не соглашусь.
CRUD и CQRS всего лишь разный подход к организации и уровень инкапсуляции кода. Буква S из SOLID.
CRUD — разделение на уровне методов
CQRS — разделение на уровне классов
То о чем вы говорите это не CRUD, это
- Command Query Separation (CQS) термин введенный Бертраном Мейером, который как раз заключается в разделении ответственностей, а соответственно и кода на уровне методов.
- Command Query Responsibility Segregation (CQRS)
Если Вам будет интересно у меня есть отдельный доклад про CQS/CQRS — https://www.youtube.com/watch?v=V24L4a9FFps
CRUD как базовый концепт не говорит вам о том как организовывать код. CRUD это такое себе связующее звено на уровне кода, связывающее команды HTTP (GET, POST, PUT, DELETE) с SQL запросами (INSERT, SELECT, UPDATE, DELETE).
Дальше вы вступаете в спор с самим собой. Тезисно:
Зачем вам вообще тогда HTTP-глаголы?
пример показывал как меняются RESTful API, при переходе с CRUD -> CQRS
HTTP в этом случае это всего лишь транспорт.
Если вы даете RESTful API, то вы вынуждены использовать глаголы HTTP.
оба примера API:
POST /product/{id}/order и POST /place-order
соответствуют требованиям CQRS, и их можно назвать command API. Все зависит от того, что в конкретном бизнесе представляет собой операция Order и как лучше ее выразить.
Я не вижу разницы между двумя этими примерами с точки зрения демострации Command API колов. А если не вижу, то почему я должен приводить ваш пример?
А вот теперь вернемся к Event Sourcing. При чем тут CQRS вообще? Что это вообще?
CQRS здесь при том, что вы не сможете построить Event Sourcing систему без использования CQRS. И это даже не мои слова, это слова Грега Янга (парня, который ввел термин CQRS).
Грег вообще считает, что CQRS без EventSourcing особо не нужен, и воспринимает его как первый шаг к EventSouring. О чем он постоянно говорит на своих докладах.
ну как-то так.boblgum
03.08.2017 12:19+1Нет, я на этом этапе с вами не соглашусь.
То о чем вы говорите это не CRUD, это
…
CRUD это такое себе связующее звено на уровне кодаСогласен, CRUD это больше. Но CRUD это и есть пример имплементации CQS.
Если вы даете RESTful API, то вы вынуждены использовать глаголы HTTP.
Если мы вообще создаем какой либо Web-API, мы вынуждены использовать глаголы HTTP.
Конечно же вы не должны использовать мой пример. Но если я пытаюсь что-либо объяснить, то стараюсь использовать более наглядные примеры. Но, каждому свое — согласен.
вы не сможете построить Event Sourcing систему без использования CQRS
это слова Грега ЯнгаА можно ссылку на пруф?
CQRS is not eventual consistency, it is not eventing, it is not messaging, it is not having separated models for reading and writing, nor is it using event sourcing.
http://codebetter.com/gregyoung/2010/02/16/cqrs-task-based-uis-event-sourcing-agh/
However, event sourcing is a completely orthogonal concept to CQRS. While they fit well together, doing CQRS does not require event sourcing, and doing event sourcing does not automatically mean we’re doing CQRS.
https://lostechies.com/jimmybogard/2012/08/22/busting-some-cqrs-myths/
You can use event sourcing without also applying the CQRS pattern.
https://msdn.microsoft.com/en-us/library/jj591559.aspx
Потому как, что нам мешает сохранять Domain Events не используя CRQS а тот же CRUD?
PUT /product/{id} -> ProductController->update(Request $r) -> ProductRepository->update($r->get('product') ->dispatch(UpdateProductEvent($r->get('product')))
А ваш доклад обязательно посмотрю :)
maghamed
03.08.2017 13:03А можно ссылку на пруф?
Не помню в какой именно из презентаций слышал именно эту формулировку.
Но вот достаточно близкая по смыслу тоже от него
https://www.youtube.com/watch?v=LDW0QWie21s&feature=youtu.be&t=7m36s
Но CRUD это и есть пример имплементации CQS.
Так говорить некорректно.
CRUD может следовать, а может и не следовать CQS.
Сам принцип CQS очень прост, каждый метод класса может быть Query или Command (нельзя одновременно совмещать и то и другое):
- Queries: возвращают результат и не изменяют наблюдаемое состояние системы, т.е. не влекут сайд эффектов, т.е. безопасны и идемпотентны по своей сути.
- Commands: изменяют состояние системы, но при этом не возвращают данные
В вашей реализации CRUD могут быть методы, которые на риде изменяют состояние. Например, операция чтения из стека — с одной стороны операция чтения, где данные вам возвращаются, с другой — она изменяет состояние наблюдаемого объекта в системе.
Т.е. эта операция не соответствует CQS.
Изменять состояние на риде — вообще одно из частых явлений во многих CRUD реализациях.
Потому как, что нам мешает сохранять Domain Events не используя CRQS а тот же CRUD?
По большому счету — ничего.
Но использовать одновременно DDD и CRUD вы теряете большинство преимуществ, которые дает вам DDD
boblgum
03.08.2017 13:34CRUD может следовать, а может и не следовать CQS.
Так можно аргументировать при реализации любого паттерна или концепта. Либо мы делаем правильно, либо нет.
Если строго следовать CQS то CRUD будет видом его имплементации.
А вот если на
readбудут прокидываться пишущие сообщения, то это уже на совести разработчика.
Кстати, мой пример был как раз на изменение состояния системы (update). А вот наreadсообщений может и вовсе не быть.
При использование CRUD в DDD вы теряете менее чем ничего если CRUD оправдан вашим бизнесом.
Забивать шурупы молотком получается лучше, чем вкручиватъ гвозди отверткой
VolCh
02.08.2017 21:01Юзер не говорит серверу, что он хочет сделать, если он и говорит кому, то пользовательскому интерфейсу, а уже он отправляет серверу команды транспортного протокола (глаголы http, путь и т. д.) на создание команд системы. Когда и как обрабатывать команды, система решит сама.
boblgum
03.08.2017 09:39+1Соглашусь с вами безоговорочно, если вы подтвердите следующий пример.
Вы хотите поговорить с вашей бабушкой/тетей/еще-кем-нибудь. Для этого вы говорите телефону то что хотели донести до собеседника. В свою очередь телефон передает какой-то системе то что вы ему сказали. Ну а система уже вашим голосом и присущей сугубо вам интонацией зачитывает ваше сообщение вашей бабушке/тете/еще-кому-нибудь
VolCh
03.08.2017 14:49Чтобы поговорить с тещеё, я сначала осуществляю действия по взаимодействию с интерфейсом телефона ("говорю телефону"), который транслирует их в команды радиомодуля телефона, ещё в какие-то, изменяющие его внутреннее состояние. Радиомодуль в свою очереди отдаёт команды базовой станции по какому-то низкоуровневому транспортному протоколу, которая вполне может решить их не выполнять, не смотря на корректность с точнки зрения транспортного уровня. Телефон создаёт и отправляет команды базовой станции, на основе тех управляющих воздействий, которые я к нему применил типа нажатия клавиш или прикосновений к экрану.
В реализациях CQRS подобных обсуждаемой, SOAP, GraphQL и прочих — HTTP лишь транспортный протокол, семантика которого вовсе не обязана следовать семантике приложения, достаточно технической правильности. Но при желании их можно сблизить, объясняя что POST /product/{id}/order постит в очередь обработки команд приложения новую команду order. Де-факто в приложении может не быть очереди, и даже команд (в смысле CQRS), но для клиента приложения такая семантика вполне корректна.
boblgum
03.08.2017 16:32+1вы описываете техническую реализацию определенной бизнес-задачи. вы описываете техническую реализацию определенной бизнес-задачи. но не смысл понятий и принцип взаимодействия
Client -> API -> System/Server
бизнес: клиент/юзер хочет поговорить с тещей (у него вообще все нормально?)
реализация:
- клиент должен использовать интерфейс (телефона).
- интерфейсом нужно уметь пользоваться, конечно (тыкать в кнопки, говорить в правильную дырку итд)
- через интерфейс клиент посылает указания системе (набери тещу)
- сервер/система (посредством хитроумной техники и используя еще какие-то протоколы. см. ваше описание реализации) прокидывает данные до тещи
все это время клиент разговаривает через и уж никак не с интерфейсом. разговаривать с интерфейсом — участь чукчей в анекдоте.
HTTP всегда лишь транспортный протокол, а не только в определенных реализациях. по определению (Transfer Protocol). все остальное — интерпретация сервером.
а в остальном все правильно говорите
VolCh
04.08.2017 13:31Клиент и юзер тут разные понятия. Клиент как раз телефон, и юзер взаимодействует исключительно с ним. Юзер не посылает команды серверу, их посылает клиент, основываясь на командах, отданным юзером через интерфейс. Ключевое слово "основываясь". Клиент преобразует команды, отданные юзером системе через интерфейс, в команды серверу. Прямая трансляция лишь простейший случай преобразования.
Вообще, согласно общепринятой классификации OSI, HTTP — протокол прикладного уровня, описывающий взаимодействие http-клиента и сервера по работе с гипертекстовыми ресурсами, идентифицируемыми по URL/URI. Но благодаря большой популярности он часто используется в качестве траспортного протокола, надстройки над TCP, минимально использующего семантическую нагрузку HTTP, типа GET для запросов, а POST для команд, или вообще только один тип запросов для любых взаимодействий через некоторое прикладное API.
Протоколы прикладного уровня могут сколь угодно полно реализовывать семантическую нагрузку, в частности к этому стремятся так называемые Restful API максимально использующие семантику HTTP в виде работы с ресурсами и полного использования глаголов HTTP. Но очень часто на семантику забивают в той или иной степени в угоду прагматичности, например делая POST /order/{id}/delete вместо DELETE /order/{id}.
maxvoloshin
01.08.2017 15:25+1Хороший доклад, спасибо!
Здорово что в PHP сообществе всё чаще говорят про микросервисы, DDD, и даже Actor Model.
Еще нравится движение по Event Sourcing / CQRS в Prooph
В свою очередь планируем показать миру как мы используем идеи Actor Model в PHP приложении
eao197
01.08.2017 17:47+2Зря вы привязали четыре свойства реактивных систем (responsive, resilient, elastic и message-driven) к свойствам модели акторов. Их старательно увязывают вместе продавцы услуг из Lightbend-а, которые, по совместительству, являются и разработчиками Akka, и соучастниками написания этого самого Reactive Manifesto. На самом же деле Actor Model вовсе не гарантирует, что разработанные на ее базе приложения будут иметь более-менее нормальную отзывчивость и/или масштабируемость. И, обратно, responsive+resilien+elastic+message-driven системы могут быть сделаны и без использования модели акторов.
По поводу Actors vs Microservices. Модель акторов вовсе не обязывает деплоить один и тот же инстанс приложения на все ноды. Запросто можно разрабатывать приложения на акторах так, что в одном компоненте приложения работают акторы типа X и Y, а в другом компоненте — акторы типов Z, V и W. При этом компоненты могут деплоится на разные ноды. И как раз то, что общение между акторами построено на базе асинхронного обмена сообщениями, а акторы не имеют разделяемого состояния, позволяет делать это безболезненно.
Так что Actors и Microservices в вашей терминологии соотносятся так же, как Microservices и SOA: microservices могут быть частью SOA, а акторы могут быть частью реализации микросервиса.
Ну и по поводу существующих реализаций модели акторов: имя им легион (языки программирования: https://en.wikipedia.org/wiki/Actor_model#Later_Actor_programming_languages, фреймворки для универсальных языков: https://en.wikipedia.org/wiki/Actor_model#Actor_libraries_and_frameworks). Сам же Erlang создавался без оглядки на Actor Model (автор Erlang-а описывая историю разработки языка не говорил, что использовал модель акторов).
maghamed
01.08.2017 20:53-1На самом же деле Actor Model вовсе не гарантирует, что разработанные на ее базе приложения будут иметь более-менее нормальную отзывчивость и/или масштабируемость.
Здесь не соглашусь, так как именно эти свойства являются в модели Акторов основопологающими.
И многие системы применяют модель Акторов, чтобы достичь масштабируемости. Например Twitter использует Actor-ов для отсылки твитов именно для масштабирования
Notably, a queuing system, kestrel, that mediates between Twitter’s web user interface and the processing of “Tweet following” and sending tweets was written in Scala and implements Actor. This implementation is much simplified from other implementations, is more reliable, and scales to handle billions of tweets.
Сам же Erlang создавался без оглядки на Actor Model (автор Erlang-а описывая историю разработки языка не говорил, что использовал модель акторов).
В Erlang Actor-ы называются process, но при этом они не перестают быть Акторами.
Так как основные три ответственности Акторов у process соблюдаются:
— создавать новые акторы
— посылать сообщения
— устанавливать, как следует реагировать на последующие полученные сообщения
По поводу Actors vs Microservices я с вами соглашусь. Пример с Microservices и SOA, который вы взяли из моей терминологии — очень удачный.
Для меня основная разница между Акторами и Микросервисами это гранулярность.
Actor Model достаточно fine-grained, так как Актор представляет собой эквивалент одного объекта в терминах ООП.
Микросервис представляет из себя coarse-grained сервис, и является своего рода Фасадом, состоящим из большого количества объектов (или Акторов).eao197
01.08.2017 21:38+2Здесь не соглашусь, так как именно эти свойства являются в модели Акторов основопологающими.
Вы же сами ниже описываете, что является основополагающим:
— создавать новые акторы
— посылать сообщения
— устанавливать, как следует реагировать на последующие полученные сообщения
Вот это и есть основополагающие свойства модели акторов. А свойства из Reactive Manifesto — это свойства реактивных систем, которые можно создавать и без использования модели акторов.
И многие системы применяют модель Акторов, чтобы достичь масштабируемости.
Это говорит лишь о том, что модель акторов применима и имеет некоторые преимущества в таких задачах. Но вовсе не о том, что responsive+resilient+elastic+message-driven являются свойствами модели акторов.
В Erlang Actor-ы называются process, но при этом они не перестают быть Акторами.
Сейчас Erlang считается одной из основных реализаций модели акторов. Но ирония в том, что описывая историю создания Erlang-а Джо Армстронг не говорил о том, что он использовал модель акторов в разработке Erlang-а (хотя этой модели к моменту начала работ над Erlang-ом уже было 13 лет), Erlang создавался под влиянием Prolog-а и Smalltalk-а. Так что авторы Erlang-а просто переизобрели модель акторов. И создали систему супервизоров, которой в модели акторов нет.maghamed
01.08.2017 22:10-2И создали систему супервизоров, которой в модели акторов нет.
Система супервизоров это как производная от трех пунктов выше, т.е. это уже конкретный механизм, который создан используя все три пункта.
Ну и в современных реализациях модели Акторов супервизоры стали стандартом де-факто.
AnneSmith
Идея с actors очень грамотная, и могу подтвердить, что она очень хорошо работает для сложных фронтенд приложений на Javascript и позволяет создавать универсальные компоненты и методы, которые могут быть многократно использованы в любых проектах, включая бизнес логику.
Разработка по факту превращается в настройку небольших компонентов, что очень упрощает задачу и значительно сокращает время разработки.
Хотя докладчика слушать крайне сложно, даже при наличии родного русского и свободного английского.