EventSourcing - что делать с сохраненными событиями, если изменилась структура агрегата? Ранее уже упоминалась книга by Greg Young ( https://news.1rj.ru/str/emacsway_log/547 ), и сегодня @bobko привел крайне интересный и качественный материал по этой теме:

"The Dark Side of Event Sourcing: Managing Data Conversion" by Michiel Overeem, Marten Spoor, and Slinger Jansen
- https://www.researchgate.net/publication/315637858_The_dark_side_of_event_sourcing_Managing_data_conversion

На эту статью ссылается Greg Young в своей книге, и дополняет список возможных решений.

#EventSourcing #DDD

Казалось бы, чем можно меня удивить? Но материал такого уровня превосходит все мои ожидания. Когда в нашем Объединении ИТ-Архитекторов появляются такие ребята, то я начинаю понимать, что все нервы и недосыпания были не напрасны, и меня охватывает чувство гордости за наш коллектив.

- https://news.1rj.ru/str/ru_arc/131
- https://news.1rj.ru/str/ru_arc/132
- https://news.1rj.ru/str/ru_arc/133
- https://news.1rj.ru/str/ru_arc/134
- https://news.1rj.ru/str/ru_arc/135
- https://news.1rj.ru/str/ru_arc/136
- https://news.1rj.ru/str/ru_arc/137
- https://news.1rj.ru/str/ru_arc/138

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

Спасибо @GKruglov - благодаря ему в моем мини-курсе по этой теме появилась ссылка на соответствующую главу SWEBoK (не путать с SEBoK):
- "Software Engineering Body of Knowledge (SWEBOK) v.3" (на русском)
- "Chapter 12: Software Engineering Economics"
- "Software Engineering Body of Knowledge (SWEBOK) v.4 (draft)"
- "Chapter 15: Software Engineering Economics"

Справочник восторгает своим соотношением качества к количеству информации.

Скачивается бесплатно (после заполнения анкеты).

#SDLC

🔷 "SAGA — эволюция и новые смыслы" / Геннадий Круглов @GKruglov:
- https://news.1rj.ru/str/ru_arc/165

Хочу оставить свою рецензию.

Что такое архитектурное решение? Его суть сводится к тому, чтобы бесконечно большое множество вариантов реализации сократить до одного единственного варианта. Иными словами, архитектура - это о том, как не надо делать. И здесь важно не многообразие вариантов само по себе, а те критерии, по которым их количество можно сократить.

Если не понимать решаемой проблемы, тогда никакое решение не будет правильным. Непонимание причинно-следственной связи называется в индустрии Карго-культом, а утрата семантических отношений - "Синдромом коллекционера".

Лучше всего драйверы описываются первоисточниками - уж они-то точно знают, какую проблему они решали. Они дают понимание релевантности этой проблемы решаемой проблеме.

Вот об этом доклад Гены.

Какую проблему решала SAGA? А транзакция? А атомарность? А SAGA - это транзакция? А SAGA атомарна? Почему?

Вот Sam Newman утверждает, что SAGA неатомарна, а Chris Richardson - наоборот, что она атомарна. Вероятно, кто-то из них не стал утруждаться исследованием вопроса, но кто же из них прав?

Гена зацепил довольно сложную тему, сложность понимания которой привело к такому бардаку вокруг этой темы. Каких только заблуждений по этой теме мне не приходилось слышать: и то, что SAGA - это stateless, в отличии от Process Manager, и то, что она обязана иметь компенсации, и т.д.

Была проделана колоссальная исследовательская работа по выявлению драйверов, причин, восстановлению исторического контекста и его актуализации. И много работы еще предстоит.

Материал презентации содержит сотни человеко-дней исследовательской работы, и стал возможным исключительно благодаря консолидации опыта специалистов сообщества. И мой вклад тоже отражен в этом докладе, но особенно ценным оказался вклад @beer_Roman .

Вот только малая часть агрегации информации по этому вопросу из чата @ru_arc_chat :
- https://news.1rj.ru/str/ru_arc/112

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

Конечно, хотелось бы вместить больше в этот доклад, и есть что в нем улучшить.

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

Гена зацепил еще одну, не менее важную проблему - вопрос эволюции явления. Изменяется исторический контекст. Старые понятия утрачивают историческую актуальность. На их основе возникают новые понятия. Должны ли мы наделять старые термины новым пониманием? Вот в Agile начали возвращаться проектные практики, в силу изменения исторического контекста, - он перестал быть Agile? Вот SAGA стала решать проблемы распределенных систем, а не LLT - она перестала быть SAGA? А если она стала хореографической - она остается быть SAGA? Вот появились уровни зрелости CQRS - нужно ли изменить его определение, чтобы включить в него CQS?

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

Текущий состав Комитета РОО "Объединение ИТ-Архитекторов" на ArchDays'22:
@emacsway , @elukianov , @GKruglov , @sergey486 .

Надеюсь, что с 10 декабря этот состав расширится.

@elukianov и @GKruglov выступили с докладами. Свою рецензию на один из них я приводил в предыдущем посте.

Неофициальная часть после ArchDays'22. Обсуждение SAGA затянулось до 4-х утра... 🙂 В общем, к утру хореографический вариант SAGA нам с @GKruglov показался более убедительным 🙂)

EventStorming для документирования архитектуры нередко применяется даже в литературе, но теперь с этой целью вполне можно использовать PlantUML Activity Diagram (Beta):
- https://plantuml.com/en/activity-diagram-beta

Подробнее о нотации:
- https://www.uml-diagrams.org/activity-diagrams.html
- https://www.uml-diagrams.org/activity-diagrams-reference.html
- https://www.uml-diagrams.org/activity-diagrams-examples.html
- https://www.uml-diagrams.org/activity-diagrams-controls.html

P.S. Я уже говорил в сообществе, что предпочитаю для этих целей ArchiMate "C.1.10 Business Process Cooperation Viewpoint", нотация которого практически 1:1 совпадает с EventStorming, хотя в C4Model для подобных целей предусмотрена "Dynamic diagram".

C4Model + EventStorming удачно сочетаются в документировании Agile Architecture средствами Archi.

#EventStorming #UML #Documenting

1. Организации устроены таким образом, чтобы избегать изменений структуры власти, статуса-кво между топ- и средним менеджментом, а также между средним-менеджментом и специалистами.

2. Первое следствие из п.1 – любая инициатива по изменению будет сведена к переопределению существующей либо к вводу новой терминологии, по сути означающей то же самое, что и до изменений, но позволяющей поддерживать статус-кво.

3. Второе следствие из п.1 – любая инициатива по изменению будет высмеяна как «пуристическая», «теоретическая», «излишне революционная» и «требующая приземления на реалии организации», что мешает началу работ по устранению существующих проблем и сохраняет статус-кво руководителей и специалистов.

4. Третье следствие из п.1 - если после внедрения изменений некоторые менеджеры и специалисты не нашли себе места, то они становятся “коучами/тренерами“ в рамках этих изменений, часто усиливая влияние п.2 и п.3.

5. Культура определяется структурой (следует за ней).

- https://less.works/ru/less/structure

Illustrated Essential Kanban Condensed Notebook
https://kanban.university/illustrated-notebook/

Очень удачная брошюра в картинках, кажется гораздо лучше подходит для первого знакомства с методом, чем "Канбан гайд". Задизайнили польские ребята.

Куда я пропал?

1. Произошли кое-какие изменения личного характера, в результате чего пришлось поменять место работы.

2. Мне всегда нравилось больше создавать команды, нежели системы. Признаюсь, что в тарелке архитектора я чувствовал себя не совсем уютно. По этой причине, имея на руках оффер на позицию архитектора и оффер на позицию CTO, я выбрал второе.

Новая должность требует отдачи, и свободного времени почти не остается.

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

Сегодня очень нужен грамотный тестировщик, со знанием средст автоматизации e2e, CDC, out-of-process component tests (и средств изоляции - Mountebank, Wiremock), ATDD и BDD тестов. Желателен опыт в IoT.

Обращайтесь в личку: @emacsway

Потребность в кадрах постоянная, т.к. количество проектов постоянно растет. Только в этом году нужно запустить как минимум 12 проектов, что означает быстрый карьерный рост, т.к. будем выстраивать уровни управления Program Management и Portfolio Management. На среднесрочном горизонте просматривается около 90 проектов.

[UPDATE]: Москва, возможна удаленная работа.

[UPDATE2]: Канал сохранит свою тематику. Скоро вернусь к публично-общественной деятельности. Работа над Reference Application будет продолжена.

конкурент ChatGPT от Google - LaMDA: https://blog.google/technology/ai/lamda
————————
LaMDA’s conversational skills have been years in the making. Like many recent language models, including BERT and GPT-3, it’s built on Transformer, a neural network architecture that Google Research invented and open-sourced in 2017. That architecture produces a model that can be trained to read many words (a sentence or paragraph, for example), pay attention to how those words relate to one another and then predict what words it thinks will come next.
————————
оказывается, Google заоупенсорсил нейронку Transformer в 2017, а OpenAI её доработал )). и стал конкурентом гуглу (в конкретной нише) )).
————————
супер респект гуглу. я его за это уважаю. он двигает оупенсорс, и тем самым развивает всю индустрию. пофик даже, что сам себе конкурентов рожает. точно, достойно уважения.
————————
(не относится к делу)
IBM, кстати, такой же - серый кардинал всей индустрии и всего прогресса, который тут происходит. их несколько - таких кардиналов.
————————
(ну и, возвращаясь к гуглу)
Google ещё, тоже, вкидывает в Deepmind Flamingo - наблюдает за "успехами". и потом будет смотреть: "что и как".
в Hadoop такой подход назывался - Speculative Execution. а у дедушки Фаулера - Sacrificial Architecture )).
————————
ну и итог:
у каждого крутого вендора есть свой аналог. у гугла - speculative execution (sacrificial architecture): BERT, Transformer-XL, LaMDA, Deepmind Flamingo.

https://www.infoq.com/presentations/automation-testing-architecture
прикольно Владик разложил про тестирование архитектуры ))

🔷 The Web API Checklist -- 43 Things To Think About When Designing, Testing, and Releasing your API
https://mathieu.fenniak.net/the-api-checklist/

💬 Однажды Петька спросил у Василия Ивановича: В чём разница между идеологией, логикой и философией?

— Видишь, Петька, вон идут чистый и грязный. Кто из них пойдёт в баню?

— Ну, грязный.

— Нет, Петька. У грязного идеология быть грязным, а у чистого — быть чистым. Грязный в баню не пойдёт. Чистый пойдёт в баню.

— А логика?

— Видишь они уже поближе — чистый и грязный. Кто из них пойдёт в баню?

— Ну, чистый.

— Зачем же чистому идти в баню — он и так чистый. Грязный пойдёт в баню.

— А философия?

— Вот они уже подошли — чистый и грязный. Кто из них пойдёт в баню?

— Ну, грязный … нет чистый … нет грязный… не знаю что и думать, Василий Иванович.

— Вот это и есть философия.

Обратите внимание на то, что Петька, столкнувшись с трудностью в решении, кто пойдёт в баню, переходит от чистого и грязного к самому мышлению — «не знаю что и думать». Именно мышление не о чистом и грязном, а о самом мышлении (о чистом и грязном), Василий Иванович охарактеризовал как философию. Вслед за Василием Ивановичем, мы зададим сущность философии как мышление о мышлении о мире.

— Виталий Яковлевич Дубровский:
Введение в общую теорию деятельности. Лекция 1. Введение в системо-деятельностный подход

https://gtmarket.ru/library/articles/6554/6555