Forwarded from Russian Association of Software Architects (Sergey Baranov)
Тем временем вышел второй, декабрьский, номер журнала IT-архитектор от @ceprojilisty: https://www.ozon.ru/product/zhurnal-it-arhitektor-1345346994/
🔥15👎1
Забавный случай приключился у знакомых на проекте 🙂
Есть два статуса - не оплачено и бесплатно.
Оба статуса в реализации вычисляются на основе размера внесенной оплаты.
Как отличить «не оплачено» от «бесплатно», когда они вычисляются на основе одного и того же условия?
Вот чтоб не было таких курьезов мы и строим модели предметных областей 🙂
Есть два статуса - не оплачено и бесплатно.
Оба статуса в реализации вычисляются на основе размера внесенной оплаты.
Как отличить «не оплачено» от «бесплатно», когда они вычисляются на основе одного и того же условия?
Вот чтоб не было таких курьезов мы и строим модели предметных областей 🙂
👍10😁9❤1
Event Storming – это еще не системное мышление.
Event Storming оперирует событиями. События говорят нам о том, что происходит в действитеьности. Системное мышление начинается тогда, когда происходит смещение фокуса с событий (конкретных фактов) к отслеживаемым шаблонам поведения, приводящим к этом событиям. Это ответ на вопрос: «какое повторяющееся поведение приводит к наступлению этого события?». Интереснее всего нам, конечно то, какие паттерны приводят к pivotal events. Проникая глубже, и здесь уже можно (но не обязательно) использовать DDD, можно исследовать структуру и взаимосвязи внутри системы, способствующие возникновению паттернов, определенных ранее. Это может быть и оргструктура и сущестувющие системы и различные виды потерь. Можно погрузиться сосвсем в глубину и проанализировать ментальные модели (убеждения, ценности), на основе которых сформировалась структура и связи.
Кроличья нора очень глубока 🙂
Event Storming оперирует событиями. События говорят нам о том, что происходит в действитеьности. Системное мышление начинается тогда, когда происходит смещение фокуса с событий (конкретных фактов) к отслеживаемым шаблонам поведения, приводящим к этом событиям. Это ответ на вопрос: «какое повторяющееся поведение приводит к наступлению этого события?». Интереснее всего нам, конечно то, какие паттерны приводят к pivotal events. Проникая глубже, и здесь уже можно (но не обязательно) использовать DDD, можно исследовать структуру и взаимосвязи внутри системы, способствующие возникновению паттернов, определенных ранее. Это может быть и оргструктура и сущестувющие системы и различные виды потерь. Можно погрузиться сосвсем в глубину и проанализировать ментальные модели (убеждения, ценности), на основе которых сформировалась структура и связи.
Кроличья нора очень глубока 🙂
👍10😁2🔥1
Ответы участников одного из крайних курсов по Event Storming на вопрос
«В чем преимущества Event Storming перед другими практиками моделирования?»
Нотация понятна и бизнесу и команда разработки
Узнаешь много нового
Легкая нотация
Каждый может высказаться
Нет давления лидера мнений
Можно быстро погрузить много людей
Экономно по времени
Высокая скорость погружения в контекст
Заполняет пробелы знаний о процессе
Вовлеченность команды
Погружение в бизнес-процессы
Возможность выправить бизнес процесс
Абстрагирование от конкретных технологий
Комплексное исследование предметной области
Учитываются мнения заинтересованных лиц
Определить границы ответственности различных компонентов
Разработчики становятся частью бизнеса => пишут лучшие решения
В короткие сроки определить самые проблемные области
---
Может стоит добавить и вопрос про недостатки 🤔
«В чем преимущества Event Storming перед другими практиками моделирования?»
Нотация понятна и бизнесу и команда разработки
Узнаешь много нового
Легкая нотация
Каждый может высказаться
Нет давления лидера мнений
Можно быстро погрузить много людей
Экономно по времени
Высокая скорость погружения в контекст
Заполняет пробелы знаний о процессе
Вовлеченность команды
Погружение в бизнес-процессы
Возможность выправить бизнес процесс
Абстрагирование от конкретных технологий
Комплексное исследование предметной области
Учитываются мнения заинтересованных лиц
Определить границы ответственности различных компонентов
Разработчики становятся частью бизнеса => пишут лучшие решения
В короткие сроки определить самые проблемные области
---
Может стоит добавить и вопрос про недостатки 🤔
👍9🔥1
Event Storming
Результат Timeline Enforcement
А цветное все такое, потому что оранжевых стикеров сильно не хватило 🤷♂️😂
🔥3
Инсайт участников с одной из крайних сессий Event Storming.
В начале модели кто-то разместил событие «воронка продаж сформирована». Другой участник задал вопрос «как формируется воронка продаж?» и открыл ящик пандоры.
Стало понятно, что формирование воронки по сложности не уступает основному операционному процессу работы компании, но важным инсайтом в результате обсуждения было то, что воронку воронку формируют продажи, а на последующих этапах ее могут урезать до нуля.
Например:
1. Продажи 2 месяца формируют воронку на 10.000 потенциальных клиентов, но в после старта привлечения только 10% проходят проверку на риски, и это 10% от 20% заинтересовавшихся от тех 10.000.
2. Существует специфика процессов под определенную ЦА. Конда доля этой ЦА низкая, – специфика не существенна. Если доля доходит до существенного уровня, - требуется перестройка.
3. Часть клиентов экономически более выгодны для продаж и разумный фокус - продавать там, где больше платят. Но продажи - это не всё и на обслуживании и реализации контракта, затраты и убытки могут превысить выручку, как из-за неготовности процессов, так и исходя из специфики ЦА/контракта.
Все эти выводы не видны, если рассматривать деятельность исключительно в границах продаж, или рисков или производства, но становятся очевидны, рассматривать весь домен целиком, сопровождая это продуктивными обсуждениями.
В начале модели кто-то разместил событие «воронка продаж сформирована». Другой участник задал вопрос «как формируется воронка продаж?» и открыл ящик пандоры.
Стало понятно, что формирование воронки по сложности не уступает основному операционному процессу работы компании, но важным инсайтом в результате обсуждения было то, что воронку воронку формируют продажи, а на последующих этапах ее могут урезать до нуля.
Например:
1. Продажи 2 месяца формируют воронку на 10.000 потенциальных клиентов, но в после старта привлечения только 10% проходят проверку на риски, и это 10% от 20% заинтересовавшихся от тех 10.000.
2. Существует специфика процессов под определенную ЦА. Конда доля этой ЦА низкая, – специфика не существенна. Если доля доходит до существенного уровня, - требуется перестройка.
3. Часть клиентов экономически более выгодны для продаж и разумный фокус - продавать там, где больше платят. Но продажи - это не всё и на обслуживании и реализации контракта, затраты и убытки могут превысить выручку, как из-за неготовности процессов, так и исходя из специфики ЦА/контракта.
Все эти выводы не видны, если рассматривать деятельность исключительно в границах продаж, или рисков или производства, но становятся очевидны, рассматривать весь домен целиком, сопровождая это продуктивными обсуждениями.
🔥7👍1
Циклы в Event Storming
В event storming нет циклов и нет control flow. В event storming события.
В процессах циклы чаще всего - это необходимость вернуться на предыдущий этап из-за нарушения инварианта, чтобы модель в итоге пришла в согласованное состояние (например - дозапросить недостающие документы, вносить правки). То есть циклы - это детали реализации.
Если модели согласованы и хочется цикл, то на самом деле это уже не цикл, просто тот же самый процесс.
Если хочется показать, что где-то есть цикл, просто напишите рядом комментарий.
В event storming нет циклов и нет control flow. В event storming события.
В процессах циклы чаще всего - это необходимость вернуться на предыдущий этап из-за нарушения инварианта, чтобы модель в итоге пришла в согласованное состояние (например - дозапросить недостающие документы, вносить правки). То есть циклы - это детали реализации.
Если модели согласованы и хочется цикл, то на самом деле это уже не цикл, просто тот же самый процесс.
Если хочется показать, что где-то есть цикл, просто напишите рядом комментарий.
👍15
When using an event-driven architecture, a model that is based on events must replace a model that is based on data. In the event-driven paradigm, the events are more important than the data, which still has value 👌
👍12
Стоит ли предоставлять доступ к модели предметной области через внешние API?
Tempting though it may be, it is not advisable to directly expose a domain model via RESTful HTTP.
This approach often leads to system interfaces that are more brittle than they need to be, as each change in the domain model is directly reflected in the system interface. There are two alternative approaches for combining DDD and RESTful HTTP.
…
The first approach is to create a separate Bounded Context for the system’s interface layer (..). This can be deemed a classic approach, as it views the system’s interface as a cohesive whole that is simply exposed using resource abstractions instead of services or remote interfaces.
…
Another approach is appropriate when more emphasis is placed on standard media types. (...) a domain model can be created to represent each standard media type. Such a domain model might even be reused across clients and servers, although some REST and SOA proponents view this as an anti-pattern.
Note: Such an approach is essentially a Shared Kernel (3) or Published Language (3) in DDD terms.
(c) Vaughn Vernon, Implementing Domain-Driven Design
Tempting though it may be, it is not advisable to directly expose a domain model via RESTful HTTP.
This approach often leads to system interfaces that are more brittle than they need to be, as each change in the domain model is directly reflected in the system interface. There are two alternative approaches for combining DDD and RESTful HTTP.
…
The first approach is to create a separate Bounded Context for the system’s interface layer (..). This can be deemed a classic approach, as it views the system’s interface as a cohesive whole that is simply exposed using resource abstractions instead of services or remote interfaces.
…
Another approach is appropriate when more emphasis is placed on standard media types. (...) a domain model can be created to represent each standard media type. Such a domain model might even be reused across clients and servers, although some REST and SOA proponents view this as an anti-pattern.
Note: Such an approach is essentially a Shared Kernel (3) or Published Language (3) in DDD terms.
(c) Vaughn Vernon, Implementing Domain-Driven Design
👍8❤2