Russian Association of Software Architects

Structured-Prompt-Driven Development (SPDD) LLM programming assistants have demonstrated considerable value, but mostly with individual developers. The internal IT organization in Thoughtworks has been using them for their teams and have developed a method and workflow called Structured Prompt-Driven Development (SPDD). Wei Zhang and Jessie Jie Xia describe a simple example of this workflow with details in github. This workflow treats the prompts as a first-class artifact, kept with the code in version control, and used to align development with business needs. They have found that developers need three key skills to be effective: alignment, abstraction-first, and iterative review. more… via Martin Fowler

401 meetup – call for papers Друзья, пишу поделиться отличной новостью! Анонсирую оффлайн-митап про Identity & Access Management (IAM) в Москве 27 мая. Концепция: свободный вендор-независимый митап для сообщества. Подробности и начало регистрации для участников будут объявлены позднее, а пока приглашаю спикеров заявиться с докладами. Очень жду и приветствую доклады про аутентификацию, управление доступом и смежные области. Это будет классная возможность выступить на релевантную аудиторию. Тайминг 35-40 минут. Запись постараюсь организовать, чтобы материалы были доступны. Принимаем любые идеи, крутые технические или архитектурные доклады всегда в цене. А если вам нужно вдохновение, вот темы, о которых особенно хочется послушать:

- Аутентификация и авторизация: MFA, passwordless, адаптивная risk-based аутентификация, Just-in-Time Access, политики и модели контроля доступа - Протоколы и стандарты: интересные, новаторские практики использования OAuth 2.0, OIDC, SAML, применение новых RFC и спецификаций - Безопасность identity: Identity Threat Detection and Response (ITDR), уязвимости, атаки на аутентификацию, контроль доступа и меры защиты от них - Практика и highload: опыт использования “нестандартного” Open Source (Ory, Casdoor, ZITADEL, etc.), адаптация IAM под высокие нагрузки и специфичные НФТ, разработка собственных IAM-решений - Новые вызовы: аутентификация и контроль доступа для AI-агентов и MCP - Enterprise-задачи: B2B IAM, федерации, мультитенантность - Customer IAM (CIAM): UX и безопасность, управление аккаунтами и согласиями, social login - Архитектура: аутентификация и контроль доступа в распределенных системах, service-to-service взаимодействия, SPIFFE - Интеграции: комплексные решения из нескольких компонентов: IdM, IAM, SIEM, API Gateway, etc.

⛔️ Для подачи заявки на доклад заполняйте форму. Прием заявок открыт до 1 мая (но времени не так много, не затягивайте). Со всеми заполнившими форму свяжемся. По вопросам можно писать Андрею Кузнецову. Сомневаетесь, подходит ли ваша тема? Оставляйте заявку – обсудим и подумаем вместе. Мы открыты к специалистам с различным опытом и профилем. Если у вас есть идея доклада, но вы никогда не выступали и переживаете, мы поддержим и поможем подготовиться <3 Напоследок TLDR: 📆 27 мая оффлайн в Москве, площадку согласился предоставить Яндекс 📩 Заявки на доклады присылайте в форму до 1 мая Stay tuned! #announce #iam_general

Новый кейс в Архитектурных Этюдах! «Расхождение между учетной системой и реальностью на складе» Как построить архитектуру информационной системы управления складом, при которой физическое состояние склада и его цифровое отображение остаются синхронизированными в реальном времени несмотря на то, что операции с материалами выполняют десятки людей, не заинтересованных в корректном вводе данных? https://t.me/c/archicases/9360

Хм. Раньше настройки опроса в Телеграм по-умолчанию были такими: • Можно выбрать только один вариант ответа Теперь по-умолчанию через десктопное приложение осталось как и было раньше (можно выбрать только один вариант ответа), а в мобильной версии по-умолчанию теперь: • Можно выбрать несколько вариантов • Перемешивать варианты ответа при каждом отображении (новая настройка) Вот я и создал опрос, через мобильное приложение, мда 🙂 Вайбкодить начали, что ли 🙂

Новый кейс в архитектурных этюдах «Бонусы в архитектуре процессинга» https://t.me/archicases/8989/8990

24-29 марта в Рабате, Марокко, проходит международная конференция в области компьютерной лингвистики EACL Исследователи Института AIRI представляют на ней 13 работ⤵️ Основной трек ◼️SPARTA: Evaluating Reasoning Segmentation Robustness through Black-Box Adversarial Paraphrasing in Text Autoencoder Latent Space ◼️Multimodal Evaluation of Russian-language Architectures ◼️Wikontic: Constructing Wikidata-Aligned, Ontology-Aware Knowledge Graphs with Large Language Models ◼️Out of Distribution, Out of Luck: Process Rewards Misguide Reasoning Models ◼️Confidence Leaps in LLM Reasoning: Early Stopping and Cross-Model Transfer Студенческий трек ◼️Bring the Apple, Not the Sofa: Impact of Irrelevant Context in Embodied AI Commands on VLA Models ◼️Acceleration of Backpropagation in Linear Layers of Transformer Models Based on Gradient Structure ◼️Detecting Overflow in Compressed Token Representations for Retrieval-Augmented Generation Трек Demo ◼️DeepPavlov Strikes Back: A Toolkit for Improving LLM Reliability and Trustworthiness Трек Findings ◼️Feature Drift: How Fine-Tuning Repurposes Representations in LLMs Воркшоп TeachNLP ◼️From Standard Transformers to Modern LLMs: Bringing Dialogue Models, RAG, and Agents to the Classroom Воркшоп NLP4MusA ◼️Learning When to Personalize: LLM Based Playlist Generation via Query Taxonomy and Classification Воркшоп NLP and LLMs for the Iranian Language Family ◼️Shughni Machine Translation Enhanced by Donor Languages Делимся кадрами из Северной Африки 📷 #AIRIнаКонфе

Провёл собственное исследование по языкам программирования будущего. В целом, дядька Боб правильно уловил ветер и выдвинул правильные требования к языку программирования для AI: - гомоиконичность; - явные типы; - никаких скрытых потоков управления; - контракты встроены в язык. Но это пока просто идея. Не реализовано даже формальной верификации контрактов. Типы явные, но это скорее аннотации, чем Хиндли-Милнер. Нет алгебраических типов с exhaustive matching (хотя tagged unions упомянуты). Нет вывода типов. Если цель - ИИ как полноценный разработчик, нужен язык, который максимизирует вероятность того, что сгенерированный им код корректен. Это значит: сильная система типов (компилятор ловит ошибки ИИ), простота (меньше галлюцинаций), достаточный объём кода в обучающих данных, и путь к формальной верификации. Lean 4 - стратегически самый интересный, но практически самый рискованный. Если через 5-7 лет Lean станет практическим языком программирования, выбравшие его сейчас окажутся впереди всех. Но не сегодня. На сегодняшний день выделяются два языка. Rust - первый кандидат. Огромный объём обучающих данных, ИИ пишет на нём уверенно. Borrow checker отсекает ошибки с памятью. Система типов ловит логические ошибки. Verus, rocq-of-rust, Aeneas для верификации. Экосистема зрелая. Один минус - сложность языка увеличивает вероятность, что ИИ сгенерирует компилируемый, но неидиоматичный код. Тем не менее, строгость компилятора это компенсирует. Ownership-модель - это фундамент, на котором можно строить доказательства. Правила Rust устраняют настолько много трудноформализуемых случаев, что это делает его одним из самых удобных современных языков для применения формальных методов. OCaml - второй кандидат. Меньше обучающих данных, но язык проще, и паттерны более предсказуемые. Алгебраические типы и exhaustive pattern matching - идеальный формат для ИИ-генерации: он описывает все случаи, компилятор проверяет, что ИИ ничего не пропустил. Gospel (Generic OCaml SPEcification Language) - tool-agnostic язык формальных спецификаций для OCaml. Именно поэтому OCaml используется в финтехе. Экосистема, правда, уступает Rust. Вишенка на торте - Camlp5. Это OCaml с Lisp-синтаксисом. Типы, компиляция, всё как в OCaml, но добавлена гомоиконичность. S-выражение - это одновременно и программа, и структура данных, которую можно анализировать, трансформировать, генерировать другой программой. Это не макросы как синтаксический сахар - это фундаментальное свойство: программа может порождать программы так же естественно, как оперировать числами. Программирование перестаёт быть написанием инструкций и становится написанием ограничений. Победят языки, в которых спецификацию невозможно написать неоднозначно. Дейкстра мечтал об этом полвека назад. Но раньше не было генератора, способного превратить спецификацию в код. Теперь он есть - и узкое место сместилось от написания кода к доказательству его корректности. Это возвращает нас к тому, с чего начался ML (Робина Милнера) - к языку, созданному для доказательства теорем. Круг замыкается. Милнер в начале 1970-х в Эдинбурге строил LCF - Logic for Computable Functions - систему для доказательства теорем. Ему нужен был язык, в котором на уровне системы типов невозможно было бы сконструировать невалидное доказательство. Так появился ML - Meta Language. Пятьдесят лет спустя мы приходим к той же задаче, только с другой стороны. Милнер хотел, чтобы человек писал доказательства, а машина их проверяла. Мы идём к тому, что машина будет писать код, а формальная система - проверять его корректность. Задача та же - гарантия корректности через типы. Только роли поменялись. ML был создан как язык для мира, где код должен быть доказуемо правильным. Этот мир тогда не наступил, потому что индустрии было важнее "быстро и дёшево", чем "правильно". Но если генерация кода становится бесплатной, а цена ошибки растёт - "правильно" побеждает. И оказывается, что фундамент для этого был заложен полвека назад в Эдинбурге.

Провёл собственное исследование по языкам программирования будущего. В целом, дядька Боб правильно уловил ветер и выдвинул правильные требования к языку программирования для AI: - гомоиконичность; - явные типы; - никаких скрытых потоков управления; - контракты встроены в язык. Но это пока просто идея. Не реализовано даже формальной верификации контрактов. Типы явные, но это скорее аннотации, чем Хиндли-Милнер. Нет алгебраических типов с exhaustive matching (хотя tagged unions упомянуты). Нет вывода типов. Если цель - ИИ как полноценный разработчик, нужен язык, который максимизирует вероятность того, что сгенерированный им код корректен. Это значит: сильная система типов (компилятор ловит ошибки ИИ), простота (меньше галлюцинаций), достаточный объём кода в обучающих данных, и путь к формальной верификации. Lean 4 - стратегически самый интересный, но практически самый рискованный. Если через 5-7 лет Lean станет практическим языком программирования, выбравшие его сейчас окажутся впереди всех. Но не сегодня. На сегодняшний день выделяются два языка. Rust - первый кандидат. Огромный объём обучающих данных, ИИ пишет на нём уверенно. Borrow checker отсекает ошибки с памятью. Система типов ловит логические ошибки. Verus, rocq-of-rust, Aeneas для верификации. Экосистема зрелая. Один минус - сложность языка увеличивает вероятность, что ИИ сгенерирует компилируемый, но неидиоматичный код. Тем не менее, строгость компилятора это компенсирует. Ownership-модель - это фундамент, на котором можно строить доказательства. Правила Rust устраняют настолько много трудноформализуемых случаев, что это делает его одним из самых удобных современных языков для применения формальных методов. OCaml - второй кандидат. Меньше обучающих данных, но язык проще, и паттерны более предсказуемые. Алгебраические типы и exhaustive pattern matching - идеальный формат для ИИ-генерации: он описывает все случаи, компилятор проверяет, что ИИ ничего не пропустил. Gospel (Generic OCaml SPEcification Language) - tool-agnostic язык формальных спецификаций для OCaml. Именно поэтому OCaml используется в финтехе. Экосистема, правда, уступает Rust. Вишенка на торте - Camlp5. Это OCaml с Lisp-синтаксисом. Типы, компиляция, всё как в OCaml, но добавлена гомоиконичность. S-выражение - это одновременно и программа, и структура данных, которую можно анализировать, трансформировать, генерировать другой программой. Это не макросы как синтаксический сахар - это фундаментальное свойство: программа может порождать программы так же естественно, как оперировать числами. Программирование перестаёт быть написанием инструкций и становится написанием ограничений. Победят языки, в которых спецификацию невозможно написать неоднозначно. Дейкстра мечтал об этом полвека назад. Но раньше не было генератора, способного превратить спецификацию в код. Теперь он есть - и узкое место сместилось от написания кода к доказательству его корректности. Это возвращает нас к тому, с чего начался ML (Робина Милнера) - к языку, созданному для доказательства теорем. Круг замыкается. Милнер в начале 1970-х в Эдинбурге строил LCF - Logic for Computable Functions - систему для доказательства теорем. Ему нужен был язык, в котором на уровне системы типов невозможно было бы сконструировать невалидное доказательство. Так появился ML - Meta Language. Пятьдесят лет спустя мы приходим к той же задаче, только с другой стороны. Милнер хотел, чтобы человек писал доказательства, а машина их проверяла. Мы идём к тому, что машина будет писать код, а формальная система - проверять его корректность. Задача та же - гарантия корректности через типы. Только роли поменялись. ML был создан как язык для мира, где код должен быть доказуемо правильным. Этот мир тогда не наступил, потому что индустрии было важнее "быстро и дёшево", чем "правильно". Но если генерация кода становится бесплатной, а цена ошибки растёт - "правильно" побеждает. И оказывается, что фундамент для этого был заложен полвека назад в Эдинбурге.

https://github.com/vladikk/modularity от Vlad Khononov.

Постепенно анализирую тренды через структуру вакансий архитектора, включая прошлый год. Покрутил данные через opus 4.6, получил интересные выводы. Категории – это кластеры, в которые собираются отдельные требования и обязанности. Обозначения 🔴 Вымирает AI полностью выполняет задачу. Человеку не нужно понимать механику для получения правильного результата. Ошибку можно проверить без глубокого знания. 🟡 Трансформируется AI выполняет задачу, но без человека с пониманием контекста результат регулярно неверный или неприменим к конкретной ситуации. Человек нужен как «переводчик» между реальностью и AI. 🟢 Растет в цене AI не может получить нужный контекст в принципе, потому что он существует вне текста: в организации, в истории решений, в неявных требованиях заказчика, в понимании цены ошибки.

The Architecture of Open Source Applications

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

Все в открытом доступе. https://aosabook.org/en/

В 2019-м году выступал на первой (закрытой, поэтому записи нет) конференции Tinkoff Agile Days (тогда она так называлась) c темой «Влияние зависимостей на взаимодействие». Фактически для управленцев через архитектурные, инженерные законы и принципы, с формулами и цифрами, рассказывал о том, как масштабировать орг структуру. И там были такие выводы: ▪️При росте сокращать до возможного минимума количество вовлеченных в принятие решений заинтересованных лиц (N^2) ▪️Масштабирование за счет ▪️небольших автономных команд (2x7 > 14) ▪️небольших автономных компаний ▪️Повышение автономии в принятии решений ▪️От 80% работы внутри границ команды ▪️100% утилизация остановит работу всех, кто от вас зависит ▪️Самоорганизация или «Если бы птицы согласовывали структуру стаи?» ▪️При физической работе увеличение размера увеличивает эффективность, а основные конкуренты — крупные организации ▪️При интеллектуальной деятельности меньший размер увеличивает эффективность, а основные конкуренты — небольшие компании с хорошим опытом ▪️Субподрядчик принесет увеличение эффективности, если он самостоятелен и его можно игнорировать Просто посмотрите на это с точки зрения оснований и тактик масштабирования в архитектуре :)

Counter-Strike и смерть за укрытием Вот в этом видео https://www.youtube.com/shorts/1m27HIyluIQ наглядно показана известная ситуация, когда игрок успел спрятаться за стену и в этот момент был убит. На уровне ощущений это выглядит будто пуля завернула за угол. Но архитектурно это не "пуля догнала в настоящем", а сервер признал, что было попадание в своём восстановленном прошлом. Valve прямо описывает такие парадоксы как lag compensation: можно получить попадание уже после того, как вы на своём экране ушли за укрытие. Базовая онтология Counter-Strike - это authoritative server: сервер владеет симуляцией мира, а клиент в основном отправляет команды и получает обновления состояния. Чтобы игра ощущалась отзывчивой, клиент предсказывает свои локальные действия, но окончательная истина всё равно принадлежит серверу. Yahn Bernier описывал это для Valve-шутеров примерно так: клиент может временно предсказывать движение, но authoritative server в итоге исправляет расхождения. И вот здесь рождается ключевой трюк - lag compensation. Когда на сервер приходит команда выстрела, он не проверяет попадание только по "текущему" состоянию мира. Он пытается реконструировать, что именно видел стрелок в момент нажатия, и для этого отматывает позиции других игроков назад по истории состояний. В документации Valve это прямо формулируется как rewind: сервер использует latency игрока, чтобы "вернуться во времени" при обработке команды и увидеть мир так, как его видел стрелок. А у Bernier эта же идея описана как нормализация мира на сервере к моменту действия игрока. Поэтому смерть "за укрытием" - это не баг, а цена архитектуры. Если бы сервер не делал такой rewind, игрокам с более высоким пингом пришлось бы стрелять с упреждением не только по движению цели, но и по сети: буквально целиться в место, где противник будет через десятки миллисекунд. Lag compensation нужен именно для того, чтобы стрелок мог целиться туда, где он реально видел цель, а не вручную компенсировать задержку. Но симметричная цена этого решения в том, что жертва иногда умирает уже после того, как на своём экране спряталась. Парадокс усиливает ещё одна вещь - interpolation. В сетевых шутерах клиент обычно показывает других игроков не в абсолютном "сейчас", а с небольшим буфером по истории, чтобы движение было гладким и не дёргалось от потерь пакетов. Bernier отдельно подчёркивал, что interpolation - это тоже форма латентности, и её надо учитывать при проектировании lag compensation. То есть у нас уже есть два времени: локальное "сейчас" и тот немного задержанный образ противника, по которому реально целится стрелок. В CS2 Valve добавила ещё и sub-tick architecture: сервер теперь знает точный момент, когда началось движение, был сделан выстрел или брошена граната. Это делает тайминг точнее, но не отменяет саму онтологию. Точное время не убирает тот факт, что попадание в Counter-Strike, это решение authoritative runtime над реконструированным прошлым, а не простая физика "что я сейчас вижу на своём экране". Именно поэтому мне нравится смотреть на Counter-Strike через призму inversion of control. В локальной игре нам кажется, что причинность принадлежит клиенту: я навёлся, я нажал fire, я попал. В сетевом Counter-Strike это не так. Клиент не владеет фактом попадания. Это по сути архитектура интентов, но в CS, потому что по факту клиент публикует intent, выраженный в форме команды. А дальше уже внешний рантайм, то есть authoritative server, решает, в каком историческом срезе мира этот выстрел должен быть интерпретирован. Иными словами: не player fires -> target dies а player submits intent -> server reconstructs world -> hit becomes valid or not Это и есть настоящая инверсия контроля, при которой нет управления собственным выстрелом до конца, но он передаётся в чужой control plane, который уже им управляет. P.S. А ещё этот пример демонстрирует, что (трендовая в 2025 году во всяких блокчейнах) архитектура интентов - это тоже есть форма инверсии контроля на уровне исполнения.

Как архитектор готовится к передаче системы в эксплуатацию Тимофеев Денис Cloud.ru Передача в системы в эксплуатацию - это не дело архитектора Именно так начинается это выступление :) Денис сразу начинает с того, что архитектор – это уже одной ногой владелец продукта, что в целом отражает тенденции отрасли. Но тут же делает разворот – это не все, об инфраструктуре теперь тоже нужно думать и думать куда больше, чем архитектор думал об этом раньше. Выступление раскладывает деятельность через системный подход – сразу отделяя структуру (инфру) от функции (конкретные рабочие процесс). Далее повествование строится вокруг инфраструктуры. Пожалуй, стоит привести цитату Дениса, которая точно отражает на концептуальном уровне, что вообще такое передача в эксплуатацию: «Передача в эксплуатацию – это изменение ответственности за эксплуатационные задачи конкретной ИС». А дальше... А дальше придется смотреть само видео, потому что рассказать его суть - это рассказать буквально все, в выступлении плотный и конкретный контент: - Чеклист передачи в эксплуатацию - Процесс приемки, описанный по шагам - Вовлеченные роли - Отработка инцидента Отличное, легкое для просмотра и емкое выступление ✍️ VK: https://vk.com/video-184472537_456239210 Youtube: https://youtu.be/g8rEUA8iPjc

У нас в Архитектурных Этюдах новый кейс, узкий, может есть специалисты по теме. https://t.me/archicases/8747/8748

IT commodity Выше я писал о том, что множество проведенных сессий Event Storming позволяют увидеть общее и отличительное в различных организациях из одного домена. Пришло время развить эту мысль. Основной тезис: фукнции стандартизируются, но IT остается сложным и дорогим, потому что сложность перетекла из «что делать?» (бизнес-логика) в «как делать?» (NFR/качество) и роль инженера/архитектора возрастает в связи с потребностью в еще более глубоком знании матчасти для обеспечения NFR. Банки в своей основе выполняют одинаковые операции, такси выполняют одинаковые операции, доставка выполняет одинаковые операции (с точностью до NFR). Так почему системы так сильно отличаются? Наконец, можно к месту применить фразу «так исторически сложилось». И мои наблюдения через Event Storming это подтверждают. Да, я осознаю, что NFR порой определеяют до 80% целевого решения, поэтому явно акцентирую внимение на предметной области/функциональности. Конечно, есть совершенно уникальные компании, в которых стандартных решений нет или почти нет, но таких не так уж и много. Игры с уникальным сюжетом, например. Однако в стандартных областях, IT с точки зрения реализованной функциональности уже не является конкуретным премуществом, как было когда-то. Сложно это признавать, но правда сегодня такая. Почему я так считаю? Хайп хайпом, но научно-технический прогресс не остановить, он будет развиваться и то, что сегодня появляются решения на Spec Driven Development и развивается пласт решений для контроля LLM через формальную логику, только подтверждает это. Еще раз – в стандартных (стандартизированных, стандартизируемых) областях наличие функциональности перестает быть конкурентным преимуществом: когда предметная область одинакова и снаружи регулируется формальными правилами законодательства (и других стандартов), техническое решение становится взаимозаменяемым товаром (с точностью до NFR). И здесь стоит вернуться к началу этого поста, – это стандартное решение становится все дешевле и быстрее собрать из тех самых спецификаций. Кредитный конвейер? Вот спека. Конкуретным премуществом все в большей степени становятся организационные способности и рыночные факторы (связи, продвижение, сделки). То есть все упирается в реальный мир: функциональность поверх технологий стала необходимым условием для участия в рынке, но не достаточным условием для конкурентного преимущества. Выглядит так, что архитектор (как роль) будет проектировать не только бизнес-систему, но и систему, которая будет порождать бизнес-системы по спекам (platform engineering evolution?). При этом важнейшая роль отводится онтологии, как несущей конструкции домена. Помимо этого, никуда не пропадут атрибуты качества - QAS нужно будет встраивать в пайплайн как параметры/ограничения. Ну и сам механизм определения компромиссов тоже. То есть, если обобщить, то знание матчасти станет важным и по глубине и по полноте и по широте, потому что снижается уровень допустимой интуитивности, для формализации нужны твердые знания. В конкурентных рынках (такси, финтех) конкуренция идет именно на поле NFR (кто быстрее подаст машину, чье приложение не упадет в черную пятницу), а если конкуренция сместилась в NFR, а NFR реализуются инженерами через архитектуру, то IT остается конкурентным преимуществом, просто фокус сместился с «наличия функции» на «качество работы функции»

Открыт прием заявок на выступление ArchDays: https://archdays.ru Тематики те же: ▪️Процессы проектирования ▪️Инструменты проектирования ▪️Практики проектирования ▪️Обучение архитектуре ▪️Собственная разработка Пора начинать планирование выступление. В чем смысл подаваться настолько заранее? Вы можете обозначить для себя тему и цель и у вас будет огромный запас времени, чтобы целенаправленно собрать дополнительные рабочие данные и материалы (которые в противном случае прошли бы мимо вас) за длительный промежуток времени.

Формализация DDD В обсуждениях DDD в пабликах часто можно встретить аргументы, мол DDD не конкретен, надуман. Напишу этот пост, чтобы скидывать ссылку, а не писать каждый раз заново. Кому хочется формальных моделей, welcome: Z Notation: https://www.cs.umd.edu/~mvz/handouts/z-manual.pdf Она практически идеально сочетается с DDD и фактически дает математически строгое описание модели, полученной с помощью моделирования предметной области. Сущности станут переменными в Z-схеме состояния, их атрибуты - типами переменных, инварианты - предикатами, а события и команды - z-схемами операций. Схемы состояния моделируют спецификацию состояния агрегата Z Notation формально валидируемая. Аспекты проектирования (транзакционность и подобное) Z не поддерживает, так что использовать можно в связке: - Z специфицирует корректность логики доменной модели - Aggregates обеспечивают согласованность времени выполнения. Очевидно, что проектирование - кросс-дисциплинарно в своей основе и одной формально моделью не обойтись. Можно и использовать расширение Z-Object для Z-Notation. Можно прикрутить еще TLA+ для агрегатов, это еще одна формальная спецификация: https://lamport.azurewebsites.net/tla/tla.html Многое в DDD - это рекомендации, рекомендации не формализуемы. Формализовать до определенного уровня можно тактические паттерны, но не стратегические, да и не к чему это. Однако возникает другой вопрос к любителям все формализовать, - а вы сами-то формальными моделями пользуетесь в повседневной работе? Проще и полезнее с прикладной точки зрения разобраться в DDD, который кросс-дисциплинарен или в паре формальных логик, выражение которых в отличие от модели Event Storming или диаграммы контекстов больше никто не поймет? Давайте уж лучше использовать полезные, широко применяемые инструменты, чтобы двигать индустрию вперед, а не пытаться показаться самыми умными через употребление умных слов, которые несмотря на всю правильность, в прикладном ключе усложняют жизнь в широком смысле. И я не против формальных методов, но там, где они приносят реальную пользу, а не для попыток за счет их существования обесценить другие полезные методы и подходы.