Сразу за SQAdays EA идет AnalystDays EA, и теперь заметки оттуда. Татьяна Половинкина. Система D5 = DDD+DD и при чем тут аналитики? Насыщенный доклад про Domain Driven Design и Data Driven. Основной тезис: в 2020 концепт ограниченных контекстов DDD добрался-таки до проектирования хранилищ данных и на смену централизованным хранилищам пришел Data Mesh. До этого все было централизованным, от переезда DWH, известных с 1980х в Data Lake в 2000 ничего принципиально не изменилось. И теперь с этим надо жить. Ну а теперь - заметки. Аналитики - не вымрут. Потому что аналитик - специалист по изменениям - а это будет только увеличиваться. Но скоуп меняется, теперь надо все больше данные анализировать. Четвертая промышленная революция показала, что данные важны, а пятая - окончательно погрузит нас в матрицу. Концепты DDD * Ограниченные контексты: одинаковые слова воспринимаются по-разному. DRP: disaster recovery plan или distribution requirement planing. Покупатель - атрибуты. Я тут добавлю, что в одних системах покупатель - тот, кто уже совершил покупку, а в других - тот, кто потенциально готов купить и его надо до покупки довести, и это тоже разные представления. * Единый язык. Аналитик - Дата инженер - Data Scienst, BI. Data Engineer - далеко не всегда понимает смысл данных, он как дизайнер - умеет располагать и сжимать. Несколько лет назад была аналогичная проблема с админами - появились DevOps. Тут тоже будет решение. * От логики к инструментам. Есть много методик, с разными подробностями. Но во всех общий принцип, что начинаем двигаться от бизнес-логики, и можно просто именно это и делать. Я тут согласен, а если у заказчика есть любимая методика - то надо просто быстренько прикинуть, как то, что вы делаете, брендировать эnим способом - потому что очень многие методики - очень тяжеловесны и не жизнеспособны. При этом, естественно, никто не запрещает взять из методики полезное. DD - Data Driven. Тонем в потоке данных, надо как-то разбивать и научиться управлять. Масштабируемость и эволюция в каждом домене. Но! недопоминание и недоверие между доменами. Что делать? Управлять данными, определить то, что производят домены. Data Product - данные, которые нужны другим доменам. Доступные, Понятные, Надежные, Безопасные, Читаемые. Тут у меня мысль. Есть старая добрая книга Николас Вирт "Алгоритмы + Структуры данных = Программы" (1976). Насколько похоже, что все - как там, только слагаемые надо переставить и уровень абстракции в примерах поднять, чтобы перенести на современные методы? Может, перечитаю ее под этим углом зрения. Data Domain - децентрализированная распределенная система с малыми зависимостями, не ждем согласований и т.п. Два подхода. * DAAP: data as a product, выдает данные как есть * DAAS: data as a service, выдает ответы на запрос как сервис. Данные должны иметь ценность. Единообразной методики оценки ценности - нет. Поэтому вам надо самим ее извлекать. Что меняется с Data Mesh, децентрализацией данных? * Сетевая федерированная структура. Как и карта доменов в DDD, пусть укрупненно. Децентрализация управления * Поддерживать разумные исторически сложившиеся связи * Четкое понимание задач домена * Двухсторонняя конкуренция (эволюция). И дальше по отдельным направлениям. * Продукт. Множественность (повторное использование - бюджет), Разделение проблем и задач (сеньор и миддл). От MVP к Roadmap * Модульность: Анализ домена от и до. Пересмотр записимостей. Матрица коммуникация. -- Распределяет поток по людям * Данные: Ценность, Data Driven, DaaP и DaaS Вывод: думай глобально, действуй локально. Глобальное видение - но не оцепенение, а активные действия в области, где можешь. А вообще можно считать, что эти подходы применял Юлий Цезарь. Разделяй и Властвуй - это про DDD. А захватывая провинцию - он строил дороги и это тогдашний способ Data Driven.