Пошел дальше, в доменный объект (уже в вики).

Объект, соответствующий определённому понятию предметной области.

Термин доменный объект (domain object) буквально переводится на русский язык как «объект [предметной] области»...в бизнес-моделировании может использоваться термин бизнес-объект (business object).

При этом предметная область – часть реального мира, рассматриваемая в пределах данного контекста. Под контекстом здесь может пониматься, например, область исследования или область, которая является объектом некоторой деятельности.

Не продвинулся в сторону поисков распространенного и общепринятого термина =)

Значит надо сделать шаг назад и зайти со стороны значения слова domain (oxford): An area of knowledge or activity; especially one that somebody is responsible for. (+ дополнительные определения как в русском из биологии, истории и так далее).

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

Я очень четко представляю себе терминологию DDD в терминах английского языка, а вот с русским все всегда сложнее. Например, для complex в научной литературе не раз встречал слово «сложностный», а слово Scrum для 99,9% жителей РФ не имеет смысла, просто 5 букв. А для американцев оно часть культуры. И попробую переведи 🙂

Предлагаю в коммента накидать примеров ПОНЯТНЫХ, но не обязытельно строго-формальных определений предметной области/домена, или примеров, которые были бы понятны и юристу и бухгалтеру и электрику :)

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

Преза моего недавнего выступления на DotNext про то, что можно получить из модели предметной области представленной в нотации Event Storming

Когда я впервые увидел Event Storming, то подумал — вот оно. То, чего мне так не хватало. Начал изучать материалы, их тогда было не много. Все выглядело очень просто и даже как-то не верилось, что настолько просто.
Очень хотелось попробовать и первая трудность с которой столкнулся — это собрать всех в одной комнате на сколько-нибудь длительное время для моделирования.

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

Когда вы начнете применять Event Storming в жизни, вы в один момент осознаете, что таких простых событий и команд, как в примерах в интернете, в дикой природе почти не бывает, но может сформироваться представление, что вот так оно просто. Тут главное — продержаться и не навязывать свое идеализированное представление участникам воркшопа)

Продолжается прием заявок на доклады конференции по архитектуре IT-решений ArchDays 2022!

В этом году мы возвращаемся в офлайн!
Конференция пройдет 21 октября в Москве + Online-трансляция.

Основные тематики конференции:
1. Процессы проектирования
2. Инструменты проектирования
3. Практики проектирования
4. Обучение архитектуре/развитие в архитектора
5. Soft skills
6. Кейсы

Всего в программе будет около 30 докладов и 4 очных воркшопов.

Подать заявку на выступление: https://archdays.ru/#speaker

В прод идут не знания экспертов в предметной области, а предположения разработчиков (с) Альберто Брандолини

Как Асхат Уразбаев сформулировал для себя понимание Event Storming (в том числе применительно к LeanDS (https://t.iss.one/leands))

Основная задача и суперспосбность —быстро, за несколько часов, создать полную картинку того, как устроен бизнес компании (предметная модель бизнеса).

Предметная модель бизнеса позволяет, как пример:

* Создать бэклог для сложного трасформационного эпика
* Создать бизнес-глоссарий (центральное понятие в Data Governance)
* Спроектировать микросервисы внутри организации
* Моделировать потоки данных в организации
* И т.д.

Для подписчиков канала скидка 20% на конференцию ArchDays по промокоду microservices_arch

https://archconf.ru/welcome_from_sergey

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

Расскажу подробнее в следующих постах.

Разбирал старые доски Miro и наткнулся на старый вопрос от 15 ноября 2020 из какого-то чата (может автор и здесь) и там же разбор этой задачи в виде event storming.

Звучал вопрос так:

Задачка: есть покупатель, рейтинг(получает за каждую покупку либо + либо -), покупки(успешные и неуспешные), уровень покупателя, опрос.
Если у покупателя кол-во успешных покупок > 200 и рейтинг более 5 то мы должны ему дать опросник.
Опросник тоже может быть done / failed(неправильные ответы). После этого он только через день сможет ответить на вопросы заново.
Внимание вопрос: где и как это делать?  
Учитываем что кол-во успешных покупок не уменьшается. Но я не могу придумать хорошего варианта

Event Storming нашел для себя еще одну нишу. Сейчас идет очередной проект по исследованию business capability с целью стартовать разработку собственных систем взамен отдельных модулей ERP и прочих систем со сложнейжей предметной областью.

Вижу в этом и плюсы и минусы.
Плюсы:
- системы максимально адаптированы к предметной области компании
- системы могут максимально быстро изменяться вслед за изменением бизнеса компании
- отсутствие зависимостей от внешних вендоров («сделайте нам вот это»)
Минусы:
- обычно это действительно сложные системы, и если у каждой компании будет своя разработка, то сотрудникам при переходе из одной компании в другую придется обучаться использованию новой системы
- разработчикам при переходе из компании в компанию потребуется больше сил и времени на погружение (это уже не SAP/ABAP Developer, а Java Developer)
- сложности с внешним аудитом - большие и тяжелые ERP и иже сними выравниваю процессы компании и облегчают прохождение внешних аудитов, дают унификацию внутри компании по части отчетности (как пример)

И я напомню, что речь о системах, с кототрыми работают тысячи человек различной компетенции в сотнях (тысячах?) компаний.

Ну и если мы возьмем масштаб страны и сложность реализации подобных систем (в терминах Event Storming – это тысячи и десятки тысяч событий), то с одной стороны это, скорее всего, создаст много рабочих мест для разработчиков, но с другой стороны это достаточно сильное дублирование усилий в, зачастую, универсальном домене.

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

Зачем?
Дело все в том, что для участника Event Storming выглядит очень простым, но от ведущего требуется четкое понимание целей сессий, как этих целей достигнуть, почему и как проявляются те или иные паттерны и как с ними работать.

Регистрация тут:
https://scrumtrek.ru/product/226/obuchenie-provedeniyu-event-storming-v-onlayn/

При этом для успеха сессии критически важно пригласить нужных людей, а это не всегда просто (но почти всегда возможно). Не стал включать в курс блок про управление ожиданиями стейкхолдеров (потому что это все-таки за скобками самого метода), но так как эта тема важна и несет ценность сама по себе, можно отдельно сходить на интенсив «управление ожиданиями стейкхолдеров»:
https://scrumtrek.ru/product/266/upravlenie-ozhidaniyami-steykholderov/

Кому интересно, приходите, в комментариях готов поотвечать на вопросы 🙂

В рамках управления ожиданиями стейкхолдеров, а в большей степени - практикам stakeholders alignment, разбирали и принципы работы с ними (на базе IASA bok):

Учитывать мнение стейкхолдеров
- Стейкхолдеры захотят повлиять на развитие ситуации в свою пользу
- Мнения различных стейкхолдеров могут конфликтовать между собой
- Важно знать, какие стейкхолдеры несут максимальную пользу в выполнении задачи

Учитывать факторы, движущие действиями стейкхолдеров
- Отдельные люди: престиж, власть, стабильность, повышение квалификации.
-  Организации: рост, увеличение бюджета/продаж, доступ к навыкам, комплаенс, конкурентное преимущество.
- Знание того, что движет стейкхолдером облегчает продвижение ему задачи и понимание стейкхолдером выгод для себя

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

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

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

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

Есть такая важная, популярная практика: матрица интерес-власть

Она дает основу, с которой можно начать работу со стейкхолдерами.

План проведения
Предусловие
– Должен быть фокусный контекст: задача, аспект деятельности
– Все участники должны хорошо разобраться в контексте перед началом воркшопа
Шаг 1: Выявление стейкхолдеров
- Начинаем с 10 минут, если динамика работы сохраняется – увеличиваем время; здесь найти максимум важнее, чем выдержать тайминг
- Индивидуально
- Один стикер - один стейкхолдер
- Не советуясь друг с другом
Шаг 2: Распределение стейкхолдеров
- Распределить по матрице
- Договориться, если есть расхождения в распределении

В Event Storming практика полезна тем, что помогает собрать стейкхолдеров первой встречи, а именно:
- тех, кто знает, какие вопросы задавать (и которым любопытны ответы);
- тех, кто знает ответы

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

Многие привыкли к такому описанию нотации Event Storming. Если в планах нет идти в архитектуру, а максимум – провести Process Modelling, можно воспользоваться описанием попроще 👇

Нотация Event Storming без элементов модели Software Design.

Вот уже и инструменты, заточенные под Event Storming начинают появляться.
Досочка: https://prooph-board.com

Поймал себя на мысли, что вот этот принцип Рэя Далио очень гармоничен Event Storming’у 🙂

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