Event Sourcing — это паттерн проектирования в информационных системах, который заключается в сохранении состояния системы путем сохранения истории всех событий, происходящих в системе.

Вместо того, чтобы сохранять текущее состояние объекта, система сохраняет все события, произошедшие с объектом, и воссоздает текущее состояние, используя эти события.

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

➖Хотите узнать подробнее, что такое event sourcing и какие преимущества и недостатки он имеет?
➖Хотите понять, какие трудности могут возникнуть при использовании этой технологии?

Тогда присоединяйтесь к нашему вебинару «Плюсы, минусы и подводные камни Event Sourcing», который состоится 28 cентября в 19:00 МСК

На вебинаре Станислав Щетинников из Сбера подробно расскажет о том, как на самом деле работает event sourcing, какие задачи он решает и какие преимущества он имеет. Мы также рассмотрим недостатки этой технологии и поделимся опытом в использовании event sourcing в реальных проектах.

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

✔️Подробности и регистрация

Мы перевели первые 5 глав миникниги
Влада Хононова What is Domain-Driven Design?

https://systems.education/what-is-domain-driven-design

Книга поможет разработчикам, аналитикам, архитекторам познакомиться с основными понятиями и концепциями DDD, прежде чем нырять в него глубоко.

Глава 1. Анализ предметных областей
Что такое предметная область?
Что такое предметная подобласть?
Типы подобластей
Основные предметные подобласти
Сложность и скорость изменений
Практические аспекты реализации
Сущность основных предметных подобластей
Обобщённые предметные подобласти
Практические аспекты реализации
Сложность и скорость изменений
Практические аспекты реализации
Кто такие эксперты предметной области?
Заключение

Глава 2. Изучение знаний о предметной области
Поиск знаний
Коммуникация
Что такое единый язык?
Язык бизнеса
Согласованность
Модель предметной области
Что такое модель?
Эффективное моделирование
Моделирование предметной области
Постоянная работа
Заключение

Глава 3. Управление сложностью при помощи ограниченного контекста
Несогласованные модели
Что такое ограниченные контекст?
Ограниченный контекст
Границы модели
Объем ограниченного контекста
Ограниченные контексты против предметных областей
Предметные подобласти
Ограниченные контексты
Взаимодействие между предметными подобластями и ограниченными контекстами
Физические границы
Границы владения
Заключение

Глава 4. Сопоставление контекстов
Сотрудничество
Партнёрство
Общее ядро
Одна команда владеет несколькими ограниченными контекстами
Заказчик-поставщик
Конформизм
Паттерн предохранительного уровня
Сервис с открытым протоколом
Раздельные пути
Проблемы коммуникации
Универсальная подобласть
Различия моделей
Когда избегать
Карта контекста
Заключение

Глава 5. Паттерны реализации бизнес-логики
Транзакционный сценарий
Активная запись
Модель предметной области
Реализация
Реализация
Сложность
Единый язык
Строительные блоки
Объект-значение
Реализация
Агрегат
Согласованность
Граница транзакции
Иерархия объектов
Ссылка на другие агрегаты
Корень агрегата
События предметной области
Другие строительные блоки
Модель предметной области, основанная на событиях
Источник событий
Источник истины
Преимущества
Заключение

#архитектура #книги #переводы

В среду в 20:00 обсудим на online встрече роль архитектора в Agile-разработке:

1. Какие ключевые отличия Agile от других моделей разработки.
2. Какие архитектурные функции важны в Agile разработке.
3. Кто должен эти функции осуществлять.
4. Как должны быть организованы процессы проектирования архитектуры в Agile процессах.

Подключение по ссылке.

Событие в Google calendar по ссылке.

Через минуту стартуем митап
«Тернистый путь инструмента цифрового проектирования».

Спикер: Виктор Выскребенцев — Исполнительный директор в ПАО Сбербанк.


Yotube-трансляция: https://www.youtube.com/live/jP_AROux7Fs?feature=shared

На встрече сегодня упоминал про «мемы» про архитекторов.

Архитектор в башне из слоновой кости. Никто не слушает такого архитектора, его работа — это потери.

Архитектор-полицейский. Постоянно говорит, как делать не надо, но не помогает и не направляет. Приводит к разговорам вида: «Как нам сделать этот проект без архитектора?»

Великий созидатель. Создает идеалистичные, далеко идущие планы без привязки к реальности. Такие архитекторы не принимают участия в развитии проекта. Они делают то, что называется BDUF.

Абстракционист. Создает простые, понятные и абстрактные модели, которые всегда верны и не дают инсайтов. Часто такие модели создаются как ответ менеджерам на жалобы о слишком сложном и непонятном представлении архитектуры, но по факту они не несут ценности организации в целом.

PowerPoint-архитектор. Описывает архитектуру в форме презентаций. Консистентность поддерживать становится адом.

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

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

Первый час разбирались с тем, какими признаками обладает Agile разработка. Обсудили такие признаки:

1. Responding to change over following a plan
2. Individuals and interactions over processes and tools
3. Working software over comprehensive documentation

Responsive достигается путём итерации, но итеративный не всегда означает Responsive.

Сделали небольшой экскурс в историю Agile.

Выявили роль стоимости разработки для достижения Responsive и это была первая отличительная функция архитектуры в Agile.

Поговорили об архитектуре в целом вне контекста Agile.

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

Поговорили о проблеме Брукса, о видении Харлана Миллза на решение этой проблемы посредством архитектуры.

Разобрались с тем, что такое модель, почему модель является границей автономности команды, как находить границы модели, что такое Bounded Context, как его выявлять посредством лингвистических конфликтов, что такое Knowledge Crunching, в каких случаях и почему делается Monolith First.

Второй час дискуссия была более сфокусированная и содержательная. Первый час получился притирочный.

Общались два с половиной часа. Обсудили половину поставленных вопросов. Подобрались к теме Dual Tracking, но не обсудили.

О целях Agile. Решение какой проблемы на него возлагали и что легло в основу его манифеста:

💬 "During the Snowbird meeting, Kent Beck said that the goal of Agile was to heal the divide between business and development. To that end, the following "bill of rights" was developed by Kent, Ward Cunningham, and Ron Jeffries, among others."
—"Clean Agile: Back to Basics" by Robert C. Martin

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

Идея Bill of Rights возникла на основе идеи Declaration of Independence (перевод):

💬 "Software development is risky. People involved have many fears of what may go wrong.
To develop effectively we must acknowledge these fears. Why do we need a software process? For the same reason that we need laws, governments, and taxes: fear.

The Declaration of Independence says:
That among these [rights] are life, liberty, and the pursuit of happiness. That to secure these rights, governments are instituted among men, deriving their just powers from the consent of the governed.

Though the profundity of these words may distract us, consider the word secure. We institute governments because we are afraid of losing our rights. By the same token, we institute software processes because we are afraid.

Customers are afraid that
- They won't get what they asked for.
- They'll ask for the wrong thing.
- They'll pay too much for too little.
- They must surrender control of their career to techies who don't care.
- They won't ever see a meaningful plan.
- The plans they do see will be fairy tales.
- They won't know what's going on.
- They'll be held to their first decisions and won't be able to react to changes in the business.
- No one will tell them the truth.

Developers are afraid, too. They fear that
- They will be told to do more than they know how to do.
- They will be told to do things that don't make sense.
- They are too stupid.
- They are falling behind technically.
- They will be given responsibility without authority.
- They won't be given clear definitions of what needs to be done.
- They'll have to sacrifice quality for deadlines.
- They'll have to solve hard problems without help.
- They won't have enough time to succeed."

—"Planning Extreme Programming" by Kent Beck, Martin Fowler

💬 "But it was here, nestled in the white-capped mountains at a ski resort, that a group of software rebels gathered in 2001 to frame and sign one of the most important documents in its industry's history, a sort of Declaration of Independence for the coding set."
—"The Winter Getaway That Turned the Software World Upside Down" by Caroline Mimbs Nyce

Проблема Брукса.

Если все части задания должны быть отдельно скоординированы между собой, то затраты на коммуникации возрастают как n(n-1)/2. Для трех работников требуется втрое больше попарного общения, чем для двух, для четырех — вшестеро. Если помимо этого возникает необходимость в совещаниях трех, четырех и т.д. работников для совместного решения вопросов, положение становится еще хуже. Дополнительные затраты на обмен данными могут полностью обесценить результат дробления исходной задачи и привести к положению, описываемому рисунком 2.4.

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

—"The Mythical Man-Month Essays on Software Engineering Anniversary Edition" by F. Brooks, ООО Издательство "Питер"

Визуализация проблемы Брукса от Greg Young:

💬 "What a fantastic visualization. What happens with communications on teams and why do we keep them small?" -- Greg Young

В качестве решения проблемы Брукс отсылает к предложению Харлана Миллза, который сравнивает как работают мясники и как работает хирург, и говорит, что архитектура подобна хирургии.

По сути дела то, что предлагал Харлан Миллз, в современном мире разработки воплощено в виде Context Map.

Харлан Миллз считал, что то, что мы сегодня называем Context Map, должен делать архитектор, обеспечивая тем самым автономность команд разработки в пределах своего Bounded Context. Это должно снизить коммуникативную нагрузку на команды разработки и повысить их эффективность.

Похожую идею продвигал и Dean Leffingwell в своей книге "Agile Software Requirements".

Список проблем, которые касаются архитектора в Agile разработке (из того, что выявили на текущий момент в процессе обсуждения):

- разрешение неопределенности требований
- сдерживание роста стоимости изменения кода (системы) с целью сохранения экономической целесообразности разрешения неопределенности требований итеративным способом
- решение проблемы Брукса по мере роста численности коллектива
- устранение психологических барьеров между сторонами разработки

Как (с помощью каких метрик) у вас в компании сейчас измеряется эффективность отдельных разработчиков?

опубликована запись вебинара: https://www.youtube.com/watch?v=e5EXP3QuVko

Какие темы вам интересны для следующих вебинаров? Напишите в комментариях 📝
Проголосуйте 👍 за тот комментарий, который отражает интересную для вас тему.

Во вторник (10.10) в 19:00 проведу здесь стрим «Введение в Event Storming»

Он в большей степени для тех, кто хочет узнать что такое Event Storming:
- Основные сценарии использования
- Основные элементы
- Основные структуры
- Основные эффекты
- Основные артефакты, которые можно получить из модели Event Storming
- Ваши вопросы и мои ответы 🙂

Основной контент где-то на 40-50 минут, но так как это стрим, то тайминг не фиксирован.

Вопросы и ответы могут быть любой сложности, не обязательно из области «введения в Event Storming» (кстати, вопросы можно уже начинать задавать в виде комментариев к этому сообщению).

Like/Share 🙂

12 октября в 18:00 присоединяйтесь к нашему бесплатному вебинару, посвященному OWASP Proactive Controls

Open Worldwide Application Security Project — это открытый всемирный проект по безопасности приложений

Мы расскажем вам о некоторых проектах, которые представлены в OWASP, и как они важны для безопасности ПО.

Узнаете, какие методы и практики безопасности рекомендуются в Proactive Controls и как они помогают защищать приложения от угроз и атак.

Не упустите шанс углубить свои знания и задать вопросы эксперту в области информационной безопасности, Алексею Краснову.

Обсудим следующие темы:
➖проекты OWASP, которые будут полезны аналитикам
➖ какие методы обеспечения безопасности описаны в Proactive Controls?
➖ с какими документами OWASP имеется связь в Proactive Controls?

Кому будет интересен вебинар:
✔️ специалистам по разработке
✔️системным аналитикам
✔️ менеджерам продуктов

Алексей Краснов
➖ Systems Analyst в команде Security Development финтех компании
➖ 10 лет в области информационной безопасности
➖ 8 лет в бизнес- и системном анализе

Запись встречи будет выложена на наш youtube канал в течение недели.

#безопасность #вебинар

Регистрируйтесь!

Посмотрите на этот график с основными факторами провалов IT-проектов.

На мой взгляд, это пример непонимания природы разработки.

Авторы статьи рекомендуют больше времени уделить оценке времени и сроков.

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

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

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

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

При этом график остается полезным, и выводы можно сделать такие:
1. С высокой вероятностью скоуп изменится, учитывайте это в оценке и закладывайте практики по управлению скоупом
2. С высокой вероятностью людей не будет хватать, или будут пробелы в компетенциях, – учитывайте в риск-модели отсутствие ключевых компетенций на некоторый срок
3. Сразу формируйте план коммуникаций, учитывайте, что это только план и конкретные методы необходимо будет стабилизировать (как, с кем, как часто коммуницировать)
4. Если на момент старта проекта нет ресурсов (окружений, каких-то коробочных решений, например), закладывайте это в риск-модель, ресурсы не появляются волшебным образом
5. В начале проекта максимально часто пересматривайте риск модель и сверяйтесь с планом, фиксируйте отклонения, начало – период максимальной неопределенности

(источник графика: https://paper.ijcsns.org/07_book/201905/20190509.pdf)

@sergey486