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

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

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

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

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

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

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

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

Для вывода важной информационной системы в промышленную эксплуатацию обычно нужно получить одобрение со стороны специалистов по информационной безопасности. Среди документации, которую они требуют, присутствуют схема, перечень и описание информационных потоков. По опыту, составление этих схем и описаний представляет определенную сложность и для разработчиков, и для архитекторов, и для аналитиков, так как это представление немного с другой точки зрения, чем они привыкли.
Это описание будет легче составить, если понимать, на что именно смотрят ИБ-шники.

1. Говоря об информационных потоках между системами и/или пользователями, безопасников интересует в первую очередь адекватность мер защиты при передаче информации и содержания передаваемой информации. Поскольку они редко могут себе позволить глубоко погружаться в контекст каждой информационной системы, которую они анализируют, то для простоты оценки адекватности мер защиты информацию принято разделять по категориями - общедоступная, служебная, персональные данные, коммерческая тайна, гостайна и т.п. Для каждой категории - свои правила и требования по защищенности. Поэтому описывая содержание информационных потоков концентрируемся на указании ключевых сущностей, которые попадают под знаковые категории. Перед описанием содержания потоков полезно ознакомиться со списком значимых категорий и описание данных, которые под эти категории попадают. Обычно этот перечень содержится в политике информационной безопасности организации, в положении о коммерческой тайне и других подобных документах, которые подписывают все (или почти все сотрудники), но мало кто их читает :) , В дополнение к бизнес-данным не забывайте указывать в том числе и способ передачи аутентификационной информации - где-то это логин пароль, а где-то JWT-токен.
Например:
Клиент -> Сервер: Аутентификация: токен аутентификации (JWT), Запросы на получение данных о заказах клиента, включает идентификатор заказа.
Сервер <- Клиент: Данные о запрошенном заказе клиента, включая персональные данные клиента (номер телефона, адрес, паспортные данные), перечень товаров и общая стоимость заказа.

2. В описании информационных потоков обращаем внимание на направление информационного обмена, и помним, что направление обмена не обязательно совпадает с направлением сетевого подключения. Например, клиент подключается к серверу, т.е. стрелочка на HLD-диаграмме будет от клиента к серверу. Да, клиент запрашивает информацию у сервера, и потом информация движется обратно, от сервера к клиенту. Большинство информационных потоков - двусторонние, построены по модели запрос-ответ. Нужно не лениться и отдельно описывать содержание потока каждого направления.

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

МТС делится информацией о внутренней кухне корпоративной архитектуры

Спасибо прекрасному каналу "Архитектура ИТ Решений" за ссылку на пост https://www.jamesmichaelhickey.com/consistency-boundary/
С одной стороны, никаких особенных открытий там не прозвучало, а с другой стороны, как-то по новому для меня зазвучала фраза, что границы агрегата определяются не столько границами сущностей и их свойств, сколько инвариантами/бизнес-правилами.
Агрегат должен быть как можно меньшего размера, чтобы снизить возможную конкуренцию, но при этом включать все данные, необходимые для контроля и соблюдения инварианта.

Про разные типы прохождения обучения со стороны обучающегося.

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

2. Целевое мотивированное обучение. Это про ситуацию, когда у человека уже есть сложности, он побился об стену и понимает, что "по наитию" проблему не решить, а потому он ищет новые (для него) пути решения. У такого человека есть большая внутренняя мотивация. Он находит курсы, тренинги, читает книги, смотрит ролики не просто так, а потому что пригорает лично у него. Он не просто изучает материал, а сразу применяет/адаптирует то что видит и слышит к своим реальным задачам, невольно думает, как он с этим будет работать в дальнейшем. По этому пути идут немногие, но именно такие люди необходимы для проведения изменений в организациях.

И в продолжение поста.

Для освоения организацией сложных практик, таких как организационное моделирование, DDD и т.п, которые в институтах еще массово не рассказывали, необходим мотивированный персонаж (хорошо если не один), прошедший обучение второго типа, и имеющий полномочия или влияние для проведения в организации массового обучение, чтобы "пропитать" коллектив новыми для него понятиями и моделями.

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

Гарантии успеха этот путь не дает, но отсутствие массовой пропитки даёт 100% гарантию неуспеха.

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

Рассказывают, что однажды к известному физику Резерфорду пришел студент и попросился в ученики.
"Не вопрос! Давайте!" - ответил Резерфорд. "А что мне делать?" - спросил студент.
Резерфорд дал ему некоторое задание и отправил изучать и работать.
Через неделю студен вернулся со словами: "Я все сделал. Что мне делать дальше?".
Резерфорд удивился и дал ему новое задание. Через пару недель студент снова пришел со словами: "Я все сделал. Что мне делать дальше?". Резерфорд очень удивился и дал новое задание.
Когда студент через какое-то время снова пришел: "Я все сделал. Что мне делать дальше?", Резерфорд его выгнал.

Как вы думаете, почему он так поступил?

ADR как навязанное сверху решение - малополезная вещь.
Если решения не записывались до того, как сверху принесли практику ADR, значит они никак не использовались в повседневной работе. И если начать их записывать, то они от этого вряд ли станут использоваться, и эта полезная в общем-то практика превратится в формальность + лишние затраты ресурсов.

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

Как же внедрять правильные практики в организации?
Вероятно, нужно требовать не столько применять конкретные практики, сколько отслеживать и предъявлять требования к другим характеристикам/метрикам деятельности - например, скорость принятия архитектурных решений, частота переделок, количество ошибочных решений и т.п., достигнуть которых сложно без применения правильных практик, инструментов, технологий. Иными словами, создавать условия, в которых в командах возникнет потребность в зарождении полезных практик.

Сегодня упоминалось про следующий хайп после микросервисов. Не уверен, что Composable Enterprise так же хайпанет, но определенный разгон уже есть, только ближе к миру EA.

Преза почитать для тех, кто пропустил.

Я из тех, кто пропустил :) И сейчас с интересом почитал.
Стало гораздо понятнее, что именно происходит сейчас нашей компании.

Since a bounded context is a boundary for a model, it could include concepts from multiple subdomains. Or a single subdomain could be modelled as multiple bounded contexts.

Subdomains vs Bounded Contexts: Areas of the domain vs boundaries of models of the domain.

#DDD

https://medium.com/nick-tune-tech-strategy-blog/domains-subdomain-problem-solution-space-in-ddd-clearly-defined-e0b49c7b586c?utm_source=pocket_mylist

Имел вчера удовольствие полуручного мерджа веток в Archi ☹️

Выяснилось следующее. Archi (точнее, collaboration плагин) хранит специализации в файлике model/folder.xml. Если изменения в составе специализаций делались в двух сливаемых ветках, то при мердже какая-то часть может потеряться, т.к. плагин детектит конфликты только на уровне объектов и диаграмм, а специализации, похоже. сливает "как получится".

В моём случае специализации добавлялись в обоих сливаемых ветках, и, похоже, при автоматическом мердже что-то потерялось. При этом Арчи полученную модель открывает, но при попытке её сохранить ему сносит мозг, он ругается про orphaned profile и не даёт сохранить модель.
Разрулить ситуацию удалось, сделав ручной rebase средствами гита, без участия Archi, и решая конфликты на уровне xml-ей. Потом руками перетащил XML файлы некоторых диаграмм из master и вроде модель открылась и заработала.

Резюме.
Составом специализаций лучше управлять в одной ветке, не нужно их мерджить средствами Archi.
#archi

Вот интересно стало, насколько связаны и коррелируют между собой DDD и DSL? Одна из сильных сторон DDD заключается в том, что программные модели формулируются на едином языке, максимально близком к понятиям предметной области - домена. Это позволяет минимизировать искажения при преобразованиях понятий и требований. Насколько я понимаю, DSL решает примерно те же задачи, но чуть с другой стороны. Тут не важно, как программа устроена внутри, фокус именно на языке, который позволяет описывать происходящее в терминах предметной области.

В студенческие годы на вычислительном практикуме я писал программу, которая решала систему линейных уравнений методом то ли вращений, то ли отражений, уже не помню. Как правило, подобные учебные программы пишутся "в лоб", в терминах массивов, переменных и действий с ними. Читать такую программу сложно, текст программы даже близко не напоминает формулы из учебника. Если что-то не работает, то понять где именно ошибка крайне сложно...

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

Да, я потратил несколько дней на отладку операторов и методов работы с матрицами. Зато сам численный метод, благодаря получившемуся DSL, я реализовал и отладил буквально за 15 минут.

К чему был предыдущий 👆 слегка спонтанный спич.
А к тому, что DDD, подобно DSL способствует выделению понятий, терминов и прочих элементов единого языка, на котором описывается как логика предметной области, так и логика работы приложения. И если модель, используемая в программной части "изоморфна" понятиям предметной области, то описание алгоритмов и действий предметной области происходит достаточно легко и просто.
В DDD сложность, как и в моем примере выше, фактически смещается с задачи программирования собственно алгоритмов и бизнес-логики в задачу создания адекватной модели реального мира предметной области.

ИМХО, важно понимать, что задача моделирования языка и задача реализации содержательной логики приложения - это разные задачи. И если в "классической" реализации основная сложность находится в реализации логики, то в случае DDD сложность смещается в сторону модели, а логика программируется и модифицируется легко и просто.
Если не разделить в голове эти две задачи, то читать книги и статьи по DDD довольно сложно, так как не понятно даже зачем все эти сложности и заморочи с контекстами, агрегатами и т.п. А они как раз таки помогают сделать адекватную модель, но не само приложение. С другой стороны, если есть адекватная рабочая модель, которая терминологически соответствует бизнесу, с гарантией соблюдения инвариантов - то сделать на ней приложение уже никакой проблемы не составляет, нужно лишь почти дословно переписать нужные утверждения из учебников, ТЗ или из протокола встречи с заказчиком.

👿Но обратная сторона DDD-подхода заключается в том, что если ты накосячил в модели, и осознал это слишком поздно, то гореть тебе в аду может потребоваться многое переписывать и переделывать, как моделей, так и алгоритмических составляющих. В этом случае ограниченные контексты играют роль переборок безопасности на подводной лодке. Если уж где-то модель "протекла", то эта ошибка не должна протекать в соседние контексты.

Интересный результат...