Комментарии 32
Разработка по факту превращается в настройку небольших компонентов, что очень упрощает задачу и значительно сокращает время разработки.
Хотя докладчика слушать крайне сложно, даже при наличии родного русского и свободного английского.
Почему "Актер"?
Поддержу вопрос и напомню, что термин актор (ударение на первый слог) существует в математической и компьютерной теории с 1973 года.
Теперь бы еще в видео исправить....
Жаль, что у вас нет замечаний по сути, Вы очень упорный могла бы получиться интересная дискуссия. А так обсуждаем некорректный перевод уже который комментарий.
Кстати, всегда думал, что на Хабре хорошим тоном принято считать уведомление автора статьи об ошибках в личном сообщении.
Что вы сразу обижаться-то? Я спросил здесь лишь потому, что вы это слово используете и в видео и в тексте. Это могло оказаться что-то новое, отличное от Модели Акторов, о чем я, а может и многие, не слыхали до этого. А если это и ошибка, на видео этого не исправить уже. А так теперь всем ясно, что вы конкретно имели в виду.
действие, которые определяется 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
Вот как раз это создаем команду и резануло по уху.
ИМХО, ну или как я понимаю CQRS, с точки зрения клиента к REST добавляется возможность конкретизировать функционал. В том смысле, что клиент все еще работает с определенным ресурсом. поэтому в вашем примере я бы все таки сделал PUT.
Сам глагол уже является командой. То есть ничего создавать не надо. На сервере из "разбитых" данных реквеста собирается объект, с которым domain может работать. Но это всего лишь трансформирование.
Но в 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 (в терминологии Эванса) вы гораздо точней описываете доменную область и процессы в ней.
честно-говоря, по вашему описанию я смутно понял, что вас резануло по уху.
То, что вы обосновываете использование POST тем, что при запросе
POST /product/{id}/activateвы создаете команду.
Таким образом вы как бы говорите юзеру, что он мол теперь будет создавать команды, а не работать с ресурсами.
Мое понимание CQRS: юзер говорит вам конкретно, что он хочет сделать с ресурсом. Он не создает, а посылает готовые команды.
С точки зрения бизнеса юзер все еще работает с ресурсом (product)
С точки зрения бизнеса юзер всего навсего хочет изменить ресурс (activate)
Ну а насчет Event Sourcing это уже другая тема :)
теперь будет создавать команды, а не работать с ресурсами.Да, вы правильно поняли, именно это и есть принципиальное отличие двух подходов.
Вы просто уже привыкли думать по CRUD-у так как в основном именно так писали, поэтому он вам кажется более логичным.
Смотрите, есть такой набор API
в CRUD API у вас все крутится вокруг ресурса. И ваши API — это фактически аксессоры которые меняют какие-то из полей этого ресурса (изменяют его состояние).
И если в случае изменения статуса или уценки продукта вам все еще кажется, что это просто изменения состояния ресурса, хотя на самом деле это бизнес операция, которая влечет за собой изменение состояния.
То в случае операции заказа продукта (Place Order) — у вас нет ресурса заказ в системе, чье состояние вы могли бы изменить. Это бизнес операция, которая повлечет за собой изменения ряда сущностей.
Здесь, кстати, очень показательный момент
юзер говорит вам конкретно, что он хочет сделать с ресурсом.Вы как программист привыкли следить за состоянием сущностей и их переходом из одного в другое. Во время отладки, при дебаге и т.д.
На самом деле в ООП сущности меняют свое состояние исключительно как side-effect выполнения каккой-то команды. Основный принцип ООП — tell don't ask .
Поэтому у вас не может быть просто изменения статуса (Out of Stock) — у вас есть команда, которая создали и которую нужно обработать.
Поэтому юзер никогда не скажет, что он хочет сделать с ресурсом, юзер просто скажет — что он хочет сделать , для него это первично. Не ресурс, а операция.
Давайте мы сначала условимся, что не будем делать выводы о том как кто думает или к чему мы привыкли. В течение последних лет 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())))ну, вот как-то так.
Так же попробуем обозначиться с тем, что же на самом деле 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. О чем он постоянно говорит на своих докладах.
ну как-то так.
Нет, я на этом этапе с вами не соглашусь.
То о чем вы говорите это не 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')))А ваш доклад обязательно посмотрю :)
А можно ссылку на пруф?Не помню в какой именно из презентаций слышал именно эту формулировку.
Но вот достаточно близкая по смыслу тоже от него
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
CRUD может следовать, а может и не следовать CQS.
Так можно аргументировать при реализации любого паттерна или концепта. Либо мы делаем правильно, либо нет.
Если строго следовать CQS то CRUD будет видом его имплементации.
А вот если на read будут прокидываться пишущие сообщения, то это уже на совести разработчика.
Кстати, мой пример был как раз на изменение состояния системы (update). А вот на read сообщений может и вовсе не быть.
При использование CRUD в DDD вы теряете менее чем ничего если CRUD оправдан вашим бизнесом.
Забивать шурупы молотком получается лучше, чем вкручиватъ гвозди отверткой
Соглашусь с вами безоговорочно, если вы подтвердите следующий пример.
Вы хотите поговорить с вашей бабушкой/тетей/еще-кем-нибудь. Для этого вы говорите телефону то что хотели донести до собеседника. В свою очередь телефон передает какой-то системе то что вы ему сказали. Ну а система уже вашим голосом и присущей сугубо вам интонацией зачитывает ваше сообщение вашей бабушке/тете/еще-кому-нибудь
Чтобы поговорить с тещеё, я сначала осуществляю действия по взаимодействию с интерфейсом телефона ("говорю телефону"), который транслирует их в команды радиомодуля телефона, ещё в какие-то, изменяющие его внутреннее состояние. Радиомодуль в свою очереди отдаёт команды базовой станции по какому-то низкоуровневому транспортному протоколу, которая вполне может решить их не выполнять, не смотря на корректность с точнки зрения транспортного уровня. Телефон создаёт и отправляет команды базовой станции, на основе тех управляющих воздействий, которые я к нему применил типа нажатия клавиш или прикосновений к экрану.
В реализациях CQRS подобных обсуждаемой, SOAP, GraphQL и прочих — HTTP лишь транспортный протокол, семантика которого вовсе не обязана следовать семантике приложения, достаточно технической правильности. Но при желании их можно сблизить, объясняя что POST /product/{id}/order постит в очередь обработки команд приложения новую команду order. Де-факто в приложении может не быть очереди, и даже команд (в смысле CQRS), но для клиента приложения такая семантика вполне корректна.
вы описываете техническую реализацию определенной бизнес-задачи. вы описываете техническую реализацию определенной бизнес-задачи. но не смысл понятий и принцип взаимодействия
Client -> API -> System/Server
бизнес: клиент/юзер хочет поговорить с тещей (у него вообще все нормально?)
реализация:
- клиент должен использовать интерфейс (телефона).
- интерфейсом нужно уметь пользоваться, конечно (тыкать в кнопки, говорить в правильную дырку итд)
- через интерфейс клиент посылает указания системе (набери тещу)
- сервер/система (посредством хитроумной техники и используя еще какие-то протоколы. см. ваше описание реализации) прокидывает данные до тещи
все это время клиент разговаривает через и уж никак не с интерфейсом. разговаривать с интерфейсом — участь чукчей в анекдоте.
HTTP всегда лишь транспортный протокол, а не только в определенных реализациях. по определению (Transfer Protocol). все остальное — интерпретация сервером.
а в остальном все правильно говорите
Клиент и юзер тут разные понятия. Клиент как раз телефон, и юзер взаимодействует исключительно с ним. Юзер не посылает команды серверу, их посылает клиент, основываясь на командах, отданным юзером через интерфейс. Ключевое слово "основываясь". Клиент преобразует команды, отданные юзером системе через интерфейс, в команды серверу. Прямая трансляция лишь простейший случай преобразования.
Вообще, согласно общепринятой классификации OSI, HTTP — протокол прикладного уровня, описывающий взаимодействие http-клиента и сервера по работе с гипертекстовыми ресурсами, идентифицируемыми по URL/URI. Но благодаря большой популярности он часто используется в качестве траспортного протокола, надстройки над TCP, минимально использующего семантическую нагрузку HTTP, типа GET для запросов, а POST для команд, или вообще только один тип запросов для любых взаимодействий через некоторое прикладное API.
Протоколы прикладного уровня могут сколь угодно полно реализовывать семантическую нагрузку, в частности к этому стремятся так называемые Restful API максимально использующие семантику HTTP в виде работы с ресурсами и полного использования глаголов HTTP. Но очень часто на семантику забивают в той или иной степени в угоду прагматичности, например делая POST /order/{id}/delete вместо DELETE /order/{id}.
По поводу 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-а описывая историю разработки языка не говорил, что использовал модель акторов).
На самом же деле 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 сервис, и является своего рода Фасадом, состоящим из большого количества объектов (или Акторов).
Здесь не соглашусь, так как именно эти свойства являются в модели Акторов основопологающими.
Вы же сами ниже описываете, что является основополагающим:
— создавать новые акторы
— посылать сообщения
— устанавливать, как следует реагировать на последующие полученные сообщения
Вот это и есть основополагающие свойства модели акторов. А свойства из Reactive Manifesto — это свойства реактивных систем, которые можно создавать и без использования модели акторов.
И многие системы применяют модель Акторов, чтобы достичь масштабируемости.
Это говорит лишь о том, что модель акторов применима и имеет некоторые преимущества в таких задачах. Но вовсе не о том, что responsive+resilient+elastic+message-driven являются свойствами модели акторов.
В Erlang Actor-ы называются process, но при этом они не перестают быть Акторами.
Сейчас Erlang считается одной из основных реализаций модели акторов. Но ирония в том, что описывая историю создания Erlang-а Джо Армстронг не говорил о том, что он использовал модель акторов в разработке Erlang-а (хотя этой модели к моменту начала работ над Erlang-ом уже было 13 лет), Erlang создавался под влиянием Prolog-а и Smalltalk-а. Так что авторы Erlang-а просто переизобрели модель акторов. И создали систему супервизоров, которой в модели акторов нет.
И создали систему супервизоров, которой в модели акторов нет.Система супервизоров это как производная от трех пунктов выше, т.е. это уже конкретный механизм, который создан используя все три пункта.
Ну и в современных реализациях модели Акторов супервизоры стали стандартом де-факто.
Ну и в современных реализациях модели Акторов супервизоры стали стандартом де-факто.Есть ли, скажем, супервизоры в такой реализации, как Orleans?
Microservices и Модель Акторов (Actor Model)