Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 26
Ну как-то так себе…
А потом:
То есть событие не просто происходит с чем-то, но и кем-то инициализировано! Только я здесь вижу противоречие?
событий, которые просто случаются, а не случаются “с” материей или “с” чем-то еще
А потом:
Итак, фиксация всех событий, реализованных в некоторой сложной системе, должна дать нам исчерпывающее (в рамках данной системы) описание каждого объекта, каждого субъекта и их отношений. По сути, полученный событийный поток содержит полную информацию о системе.
То есть событие не просто происходит с чем-то, но и кем-то инициализировано! Только я здесь вижу противоречие?
Я с вами.
В том смысле, что противоречия есть.
Я бы «прицепился» к «полноте информации».
Полнота информации — это когда мы можем предсказать состояние каждого объекта (а не статистическое распределение состояний).
Могу ошибаться, но по моим ощущениям, именно здесь происзодит водораздел между «сложными» и «не очень» системами.
В том смысле, что противоречия есть.
Я бы «прицепился» к «полноте информации».
Полнота информации — это когда мы можем предсказать состояние каждого объекта (а не статистическое распределение состояний).
Могу ошибаться, но по моим ощущениям, именно здесь происзодит водораздел между «сложными» и «не очень» системами.
Полнота информации — это когда мы можем предсказать состояние каждого объекта (а не статистическое распределение состояний).Так ведь речь идет о полном потоке событий, а не множестве событий данных в некий момент времени. То есть задача «предсказать» и не ставится.
Да фраза «полученный событийный поток содержит полную информацию о системе» не о том, что мы имеем исчерпывающее описания всех элементов системы, включая субъектов, а утверждение, что их этого потока мы можем извлечь все данные о системе.
Наверное, слово «информация» тут не самое удачное.
Как раз здесь нет противоречия: Есть система, она полна по построению (если вводите внешнее наблюдение или инициализацию, то это уже не система, а компонент модели). События происходят не с чем-то(кусками), а со всей системой, она из одного множества переходит в другое (можно считать ее множеством состояний переходов (событий) ), нет понятия одновременности, но есть череда событий.
Достаточно симпотяжная концепция, как мне кажется, но настаивать не буду. Мы так погрязли в проблеме организации одновременности события(атомарности), что возможно стоит «копать» в другую сторону.
Достаточно симпотяжная концепция, как мне кажется, но настаивать не буду. Мы так погрязли в проблеме организации одновременности события(атомарности), что возможно стоит «копать» в другую сторону.
События происходят не с чем-то(кусками), а со всей системойТо есть замечательная инкапсуляция идёт по
она из одного множества переходит в другое (можно считать ее множеством состояний переходов (событий) )при спорности подхода (с моей т.з.), хотя бы в чём его преимущество? Не понимаю. Для каких задач выгоднее использовать именно такой подход? Не «можно попытаться притянуть за уши», как пример с болтом, а реально выгоднее. Возможно, я пытаюсь придумать как это использовать на своих задачах, куда оно не применимо, а есть другие, где такой подход ляжет идеально?
///То есть в бесконечно сложной системе любое бесконечно малое событие требует держать в памяти и всю систему?
или использовать статистический подход, как Вам больше нравится.
///Для каких задач выгоднее использовать именно такой подход?
Так мы уже уперлись в «стену» объектной модели, если поведение регулярно, простая система минимальных отношений, и описывается быстро сходящимися рядами, то можно использовать объектные модели, выделяя базисы. А если базисов — континум, поверхность неустойчива… какой толк от объектов если их нельзя «развязать»(см. решения задач «трех тел» и подобных)?
или использовать статистический подход, как Вам больше нравится.
///Для каких задач выгоднее использовать именно такой подход?
Так мы уже уперлись в «стену» объектной модели, если поведение регулярно, простая система минимальных отношений, и описывается быстро сходящимися рядами, то можно использовать объектные модели, выделяя базисы. А если базисов — континум, поверхность неустойчива… какой толк от объектов если их нельзя «развязать»(см. решения задач «трех тел» и подобных)?
To Duduka
Да, спасибо. Субъектно-событийный подход появился как побочный продукт сугубо философской онтологии, в которой основными являются концепт распределенной во времени (темпоральная) системы и представление о неточечности сейчас.
Да, спасибо. Субъектно-событийный подход появился как побочный продукт сугубо философской онтологии, в которой основными являются концепт распределенной во времени (темпоральная) системы и представление о неточечности сейчас.
Конечно, противоречие. Поскольку первая фраза относится к философской онтологии самого высокого/глубокого уровня, да еще написана сто лет назад Бертраном Расселом. А вторая взята из описания прикладного метода описания сложных инженерных систем. Специально, чтобы разграничить эти две онтологии (между которыми есть связь только преемственная, а не логическая связь) в текст было вставлено замечание: "нас не должна волновать глубинная событийная онтология каждого болта".
Вот оно написано и опубликовано, теперь есть, о чем подискутировать.
Работая со сложными системами хотя бы изредка необходимо попробовать посмотреть на проблему сверху и описать, что что видишь человеческими словами.
Язык математики — это хорошо.
Но из числа прикладных специалистов больше владеет языком слов, чем языком математики.
Поэтому — спасибо автору!
По сути.
Как мне слышится из текста, автор выходит с некоторого рода манифестом некоего абстрактного субъекта АйТи (назовет его «Автоматизатор»), пришедшегодать волю решить информационные проблемы некоторому абстрактному производству.
С некоторыми положениями этого манифеста я позволю себе не согласиться.
В частности, я не согласен с абсолютизацией позиции бесстрастного наблюдателя у «автоматизатора».
В принципе, и количество болтов в системе — счетное, т.е., в принципе — все событийные онтологии учету поддаются.
Вопрос в целесообразности, т.е. — игра ресурсов и рисков.
Работая со сложными системами хотя бы изредка необходимо попробовать посмотреть на проблему сверху и описать, что что видишь человеческими словами.
Язык математики — это хорошо.
Но из числа прикладных специалистов больше владеет языком слов, чем языком математики.
Поэтому — спасибо автору!
По сути.
Как мне слышится из текста, автор выходит с некоторого рода манифестом некоего абстрактного субъекта АйТи (назовет его «Автоматизатор»), пришедшего
С некоторыми положениями этого манифеста я позволю себе не согласиться.
В частности, я не согласен с абсолютизацией позиции бесстрастного наблюдателя у «автоматизатора».
Безусловно, когда мы обращаемся к прикладным проблемам описания сложной системы, скажем, большого современного предприятия, то нас не должны волновать глубинная событийная онтология каждого болта.
В принципе, и количество болтов в системе — счетное, т.е., в принципе — все событийные онтологии учету поддаются.
Вопрос в целесообразности, т.е. — игра ресурсов и рисков.
Скрытый текст
Ну, может, потому я и остался в науке (очень прикладной), а не мигрировал в АйТи.
Видел красивые системы, не взлетевшие из-за ма-а-леьких болтиков-винтиков
Видел красивые системы, не взлетевшие из-за ма-а-леьких болтиков-винтиков
Переизобрели Event Sourcing или что?
Ценность статьи в том, что она обобщает прикладные подходы одну схему. Это одна из задач науки — дать инженерам концепцию в стиле «бери и пользуйся», чтобы не придумывали каждый свой велосипед. А если вспоминать практические применения, то мне вот сразу в голову пришёл write-ahead log.
To kekekeks
Общее с Event Sourcing только слово «событие».
Event Sourcing про учет событий, а субъектно-событийный подход про моделирование сложных бизнес систем. Но даже без вникания в суть сразу видно формальное различие — в Event Sourcing нет субъекта.
Переизобрели Event Sourcing или что?Или что. ))
Общее с Event Sourcing только слово «событие».
Event Sourcing про учет событий, а субъектно-событийный подход про моделирование сложных бизнес систем. Но даже без вникания в суть сразу видно формальное различие — в Event Sourcing нет субъекта.
Event Sourcing не про учет событий, Event Sourcing про хранение текущего состояния (агрегата) в виде потока событий (по
этому агрегату).
этому агрегату).
Вполне возможно, это так и называется. Хотя фраза «хранение текущего состояния в виде потока событий» мне кажется предельно странной: «текущее», вроде, подразумевает «единомоментное», и как его сопоставить с «потоком событий», то есть с некоторым распределением событий на промежутке времени, я не знаю. Вроде для хранения текущего состояния достаточен просто перечень атрибутов и не нужны никакие события. Или я, действительно, чего-то не знаю ))
Хотя речь, конечно, не о содержании Event Sourcing, а о том, что он не имеет ни какого отношения к ССП.
Хотя речь, конечно, не о содержании Event Sourcing, а о том, что он не имеет ни какого отношения к ССП.
Пора застолбить за собой термин (пока не застолбили другие) — «потоково-структурный дуализм», по аналогии с корпускулярно-волновым. Само понятие давно используется программистами — например, база данных может быть представлена как снапшот, или как лог транзакций, или совместно. Поток событий формирует структуру, изменения структуры формируют поток событий. Этот дуализм просматривается везде — и в объектно ориентированном программировании, и в системах управления версиями исходного кода. Беда однако в том, что обычно упор делается на одно представление, а второе рассматривается как необходимое зло, которое пытаются замести под ковер. Но насколько бы логичнее, например, рассматривать службы очередей сообщений совместно с базами данных, объединеных единым управлением транзакциями, а не отрывать их друг от друга сначала, а потом пытаться склеивать.
Пора застолбить за собой термин (пока не застолбили другие) — «потоково-структурный дуализм»Да, хороший термин )) В философской событийной онтлогии ему соответствует представление о преобразовании (редукции) темпоральной сложности в пространственную (структурную) — и обратно. И в описанном в тексте подходе подразумеваются операции переходов между событийным и объектным описанием.
Кажется, принципиальной новацией по сравнению с философскими и онтологическими основами RDF является только ввод обязательного «субъекта» события, который превращает тройку в четвёрку? Да и то обязательность его относительна, ибо есть «абсолютный» субъект.
Давайте разбираться.
1-3. Да, основу события, его содержание составляет факт, который записывается триплетом RDF (хотя там есть некоторые нюансы).
4. Если речь идет не о механизме, а о сложной бизнес-системе, то наличие субъекта принципиально (с привлечением абсолютного субъекта описываются только внешние для системы события — в основном свойства поступающих на вход объектов). Привязка событий к субъектам дает: полное описание субъектов в системе, структуру взаимодействий субъектов, представление системы (и отдельных объектов) с точки зрения субъекта/роли того или иного уровня.
А теперь то, что еще дополняет имеющуюся четверку:
5. Метка времени. События в отличии от голого RDF последовательны во времени. По сути, отпадает необходимость в 4D онтологии — временные части описываются через события смены состояния объекта, фиксируемые/производимые субъектом. Упрощается запись регулярных списков.
6. Условная (логическая) связь событий. В тексте на эту позицию формата написано не было, только намек: «факт наличия (или отсутствия) события является условием для выполнения события другим субъектом или этим же субъектом, но с другим объектом». Так вот, запись события содержит еще и логическое условие его свершения — логическое выражение из других событий (в минимальном варианте просто предыдущее событие), при true значении которого событие должно выполнится.
Итак, формат события: [Subject][RDF][IF(e1,e2,e3..)][Time]
1-3. Да, основу события, его содержание составляет факт, который записывается триплетом RDF (хотя там есть некоторые нюансы).
4. Если речь идет не о механизме, а о сложной бизнес-системе, то наличие субъекта принципиально (с привлечением абсолютного субъекта описываются только внешние для системы события — в основном свойства поступающих на вход объектов). Привязка событий к субъектам дает: полное описание субъектов в системе, структуру взаимодействий субъектов, представление системы (и отдельных объектов) с точки зрения субъекта/роли того или иного уровня.
А теперь то, что еще дополняет имеющуюся четверку:
5. Метка времени. События в отличии от голого RDF последовательны во времени. По сути, отпадает необходимость в 4D онтологии — временные части описываются через события смены состояния объекта, фиксируемые/производимые субъектом. Упрощается запись регулярных списков.
6. Условная (логическая) связь событий. В тексте на эту позицию формата написано не было, только намек: «факт наличия (или отсутствия) события является условием для выполнения события другим субъектом или этим же субъектом, но с другим объектом». Так вот, запись события содержит еще и логическое условие его свершения — логическое выражение из других событий (в минимальном варианте просто предыдущее событие), при true значении которого событие должно выполнится.
Итак, формат события: [Subject][RDF][IF(e1,e2,e3..)][Time]
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Субъектно-событийный подход к моделированию сложных систем