Я о Domain Storytelling не знал, спасибо за наводку. Сейчас быстро посмотрел материалы - там две идеи. Первая - что вместо индивидуальных интервью спецов аналитиками с последующим сведением того, что они расскажут лучше собрать вместе экспертов и команду на workshop. Для беглого знакомства, наверное, лучше, и по астрономическому времени - быстрее, а вот по человеко-часам - больше, так что эффективность сильно зависит от организации встреч.
И вторая - визуальный язык для записи этих историй. Он повышает эффективность встреч. Но пригоден только для задач документооборота, историю о выверки отчетности или другие аналитические истории на нем не запишешь.
По сравнению с Event Storming отличается язык моделирования. В ES у нас события, в DS - workflow документооборота. События - более общий язык. F еще детальность, ES просто фиксирует наличие истории, детализация - вне сессии, а DS - углубляется в нее. Так что DS можно применять для тех областей, где его язык адекватен для детализации и погружения взамен обычной проработки user story через интервью.
Это - слабое место Agile-методов. Архитектура проектируется в нулевой итерации, которая готовит старт проекта. Но там речь идет, скорее, о выборе технологий и фреймворка: взяли и погнали делать истории. А в первых историях - всегда самые распространенные сценарии: заказ оплачивается и отгружается полностью, весь товар склад находит и отгружает и так далее. То есть вместо 1:n связь 1:1, что позволяет вообще объединить сущности, расширив атрибутный состав. А дальше, когда доходит до сложных историй, выясняется, что рефакторить надо не только хранение - весь интерфейс заточен на то, что оплата - одна, а отгрузка - полная, а не частичная. И рефакторинг - дорогой.
Впрочем, часто можно не рефакторить. Не нашел склад какой-то товар - так вместо фиксации неполной отгрузки взяли и разделили заказ на два, один - отгружен, второй - нет. И оплату тоже разделили на две. Там с выпиской не будет биться по документам, но это - локальное усложнение, можно на атрибутах отработать. Вот много оплат за 1 единицу дорого товара принять - да, тут надо как-то будет придумывать при единственной оплате...
Но это все равно про фрагменты, с архитектурой сложной системы в целом с развитием получается беда быстрее, чем при развитии после проектирования. Хотя при проектировании тоже можно не угадать.
Если бизнес-заказчикам объяснять, что "вот эти объекты у нас будут во всех системах одинаковы" или "мы не будем поддерживать структуру объектов старой legacy-системы, у нас будет другая структура, и мы будем делать преобразования при интеграции" - понимают. Но да, важны объяснения в понятных им терминах. Это проблема, такая же как с диаграммами классов - она очень богатая, чтобы бизнес-заказчики ее понимали - надо использовать разумное подмножество, ограничивать себя. Иначе ты что-то нарисовал, и думаешь что объяснил важное, а они думают "ну, здесь какие-то непонятные значки, наверное техническое и неважное".
ERwin да, предлагал. Но это - уже проектирование БД, этап дизайна, а не бизнес-модели. А вот что модель предметной области должна быть целостной и непротиворечивой - учебники писали.
Потому что макеты интерфейсов не раскрывают структуру системы. Ты добавил на заказ в интерфейсах магазина поле "комментарий для курьера как проехать" или даже возможность подгрузить туда рисунок - а этого мало, еще надо протянуть через интеграцию через все системы до мобильного рабочего места курьера и там показать. Или сделал признак на заказе "отгружать по предоплате" - тоже надо учесть в алгоритмах, чтобы если предоплаты нет - склад не начинал собирать заказ и, главное, не отгрузил его. Куча прецедентов, когда про все эти связи забывали, а просто дорисовывали интерфейс.
Смотри, тут слева - модель деятельности в виде бизнес-процессов, а дальше - ее поддержка через workflow бизнес-объектов, реализованных в системе. То есть единая модель включает и предметную область и систему.
Вот смотри: сначала делаем бизнес-модель, потом из нее - требования (черный ящик), потом на их основе - дизайн. При этом требования - граница между работой бизнес-аналитика и системного аналитика, именно они сшивают модели. И именно поэтому к ним внимание, чтобы обеспечить посыл: "система, удовлетворяющая требованиям будет решать бизнес-задачу". А так - не работает. И сила DDD в том, что он три разных процесса объединил в работу с одной моделью. Напрямую прослеживая на основе модели, как такой софт будет поддерживать бизнес-процессы на требуемом уровне.
Да, мы тоже строили объектную модель предметной области через диаграммы классов UML с середины нулевых. Книги по DDD переведены позднее. Но на английском книга Эванса вышла в 2003.
Ну, да. Шаблон Business Objects был еще у Фаулера, и OOAD тоже в эту сторону работал. А параллельно развивались шаблоны, ориентированные чисто на структурирование кода - инъекции, фасады, фабрики. Проблема в том, что без них ты от Business Objects получал антипаттерн BigObject - потому что бизнес-объекты реально многообразны. А DDD предложил принцип: объекты предметной области должны прозрачно и единообразно отражаться в код. Не обязательно 1:1, это лишь самый простой способ. Можно для каждого делать DTO, контроллер, фабрику - но это должно быть единообразно. И наследование тоже можно реализовывать по-разному, но тоже единообразно.
Да, именно так: заказчикам процессные модели понятнее, чем онтологические, поэтому вместо онтологических моделей начали писать просто словарь понятий предметной области, и рисовать только процессы. А объекты появлялись уже только при проектировании приложения, в виде ER-схемы БД. Хотя был шаблон Business Object от Фаулера, который как раз говорил про использование модели предметной области как основе для проектирования объектов, что предполагало, что модель объектов мы все-таки создаем.
BPMN предполагает указание объектов и Archimate - тоже. Но без подробной проработки их структуры и атрибутов. А этого недостаточно.
Такие инструменты есть (из распространенных Enterprise Architect). Но при этом в таком режиме - с трассировкой требований, выявлением противоречий и т.п. - используются только в некоторых специальных областях с высоким требованием надежности, например, при проектировании бортового софта автомобилей (в современном автомобиле софт управляет не только автопарковкой, но и, например, тормозами - нет прямого привода от педали тормоза на колодки). Потому что сильно сложно и дорого.
Оба примера - требования, ни не раскрывают устройство системы. Модель возникает, например, когда описывается способ восстановления пароля. И дальше этот способ можно оценить с точки зрения безопасности: не сможет ли с его помощью злоумышленник получить доступ от имени конкретного пользователя, зная логин, но не зная пароля.
Аналогично про ширину колонок: сохранять настройки можно на локальном рабочем месте, или в настройках, связанных с логином пользователя (могут быть и другие варианты). В первом случае пользователь, войдя с другого компьютера все свои настройки теряет и наоборот, другой пользователь с того же компьютера получает чужие настройки. А во втором - будут сложности если пользователь работает с разных рабочих мест с разным разрешением экрана. В зависимости от того, насколько пользователю важна настройка внешнего вида таблицы сделок для его работы, могут быть разные решения.
Спасибо, учту на будущее. Потому что когда рассказываешь что-то с чем давно работаешь, не очевидно, что может быть непонятно. Попробую ответить.
Ограниченный контекст возникает из границ проекта. Сейчас прошло время больших монолитных систем, покрывающих какую-то предметной область. Собственно, оно давно прошло, все ERP - из крупных модулей. Но вот представления о том, что модель предметной области надо строить на всю область, с которой имеешь дело - осталось. А в результате ты разрабатываешь систему оптовых продаж, но она интегрируется с системами склада и ведения остатков, а в них работают не только с оптовыми продажами клиентам, но и с отгрузкой в розничные магазины, перевозками между складами и поставками. При этом эти системы в плане модернизации в перспективе может быть замена и этих систем тоже. И в результате аналитики пробовали построить модель оптово-розничной торговли целиком, задача получалась неподъемной. Или аналогично с банком или бухгалтерией - при проектировании главной книги пытались учесть все виды сделок, а их очень много. Выделение ограниченных контекстов позволяет с этим конструктивно работать. В том числе - не тянуть в модели для новых систем понятия, сформированные на основе старых, даже если с ними предусмотрена интеграция.
Почему объекты не подходят для описания работы с очередями? Потому что в них методы выполняются синхронно и результат обработки запроса гарантирован. В классических приложениях многое обеспечивали транзакции - у тебя был или успех, или откат при обработке запроса пользователя. Особая обработка возникала редко. А если у тебя асинхронная обработка на очередях, то там транзакции - в рамках обработки одного сообщения, инстанс может упасть, его работа откатится - а сообщения останутся и будут обработаны. И это - не внутреннее дело разработчика, многое из этого имеет бизнес-последствия, как минимум - вываливается на службу поддержки и это надо обсуждать со стейкхолдерами на понятном им языке. Модель акторов это позволяет. А классическая объектная модель перестает соответствовать реализации на сервисах, на ней эти ситуации обсуждать нельзя.
Но про модель акторов я в статье подробно не писал, это есть в докладе. на который ссылка. Возможно, в будущем напишу отдельную статью.
Но в данном случае у нас не алгебра, а разработка софта, и там моделью системы является представление, описывающее конструкцию системы, обычно в каком-то формализме. Например, в виде объектов, их атрибутов и методов. При этом атрибуты можно по смыслу сопоставить с отношениями, а методы - с операциями. Модель в ООП методы включает. Без них получаем только модель данных.
У Эванса в книге язык создавался для проекта. Правда, там язык появлялся сразу, а концепция контекстов - довольно далеко. Но, я с ним согласен, потому что есть тезис: все члены проекта общаются на одном едином языке, это важно. Если проект включает несколько контекстов - значит язык их должен как-то включать все вместе. И если речь везде идет о Заказе покупателя - то там один Заказ. А если у нас есть Заказ покупателя в интернет-магазин и Заказ на доставку в транспортную компанию, то слово Заказ становится запрещенным, надо пояснять. Причина, почему язык один в том, что люди с громадным трудом переключаются между языками в ходе одной коммуникации. Путаница будет, не будут выдерживать. А то, что в разных контекстах для заказа покупателя могут быть важны важны разные атрибуты - понятно.
Вопрос о требованиях - это вопрос о границах проекта. потому что требование "Организация Х должна формировать и отправлять клиентам коммерческое предложение" можно реализовать вообще без софта, с использованием Word и электронной почты, а можно поддержать софтом в той или иной мере. Граница - очень подвижная. Основной смысл использования моделей, с моей точки зрения, в том, что они позволяют представить потенциал софта: какие решения поддержать просто, а какие - нет. А если функционал софта закрыт описанием через требования, как черный ящик, то это уже нельзя, и сплошь и рядом возникают проколы, когда бизнес требует сложные фичи, думая что это просто и наоборот, не просит удобного, не зная, что это можно несложно сделать.
Это вы не в курсе. Социократия - технология организации компаний, который работает не в малых группах, а на большом масштабе, на сотни человек точно и это проверено практикой. Это - не малые группы. И это - не мной изобретенная собственная технология, она развивается международным сообществом. И именно под таким названием - потому что в основа предложена Огюстом Контом как метод, масштабируемый на все общество. И оригинальный вариант даже пробовали в 19 веке применить в масштабах отдельно взятой страны - в Бразилии, но там не получилось. Впрочем, это - в прошлом, технология была переработана и адаптирована именно для управления компаниями, это первоначально сделали в Голландии. При этом ее можно брать не целиком, а использовать отдельные шаблоны для решения конкретных проблем. А в статье (как и в докладе), я фокусировался на тех шаблонах, которые могут быть интересны и полезны для ИТ-компаний.
Я о Domain Storytelling не знал, спасибо за наводку. Сейчас быстро посмотрел материалы - там две идеи. Первая - что вместо индивидуальных интервью спецов аналитиками с последующим сведением того, что они расскажут лучше собрать вместе экспертов и команду на workshop. Для беглого знакомства, наверное, лучше, и по астрономическому времени - быстрее, а вот по человеко-часам - больше, так что эффективность сильно зависит от организации встреч.
И вторая - визуальный язык для записи этих историй. Он повышает эффективность встреч. Но пригоден только для задач документооборота, историю о выверки отчетности или другие аналитические истории на нем не запишешь.
По сравнению с Event Storming отличается язык моделирования. В ES у нас события, в DS - workflow документооборота. События - более общий язык. F еще детальность, ES просто фиксирует наличие истории, детализация - вне сессии, а DS - углубляется в нее. Так что DS можно применять для тех областей, где его язык адекватен для детализации и погружения взамен обычной проработки user story через интервью.
Это - слабое место Agile-методов. Архитектура проектируется в нулевой итерации, которая готовит старт проекта. Но там речь идет, скорее, о выборе технологий и фреймворка: взяли и погнали делать истории. А в первых историях - всегда самые распространенные сценарии: заказ оплачивается и отгружается полностью, весь товар склад находит и отгружает и так далее. То есть вместо 1:n связь 1:1, что позволяет вообще объединить сущности, расширив атрибутный состав. А дальше, когда доходит до сложных историй, выясняется, что рефакторить надо не только хранение - весь интерфейс заточен на то, что оплата - одна, а отгрузка - полная, а не частичная. И рефакторинг - дорогой.
Впрочем, часто можно не рефакторить. Не нашел склад какой-то товар - так вместо фиксации неполной отгрузки взяли и разделили заказ на два, один - отгружен, второй - нет. И оплату тоже разделили на две. Там с выпиской не будет биться по документам, но это - локальное усложнение, можно на атрибутах отработать. Вот много оплат за 1 единицу дорого товара принять - да, тут надо как-то будет придумывать при единственной оплате...
Но это все равно про фрагменты, с архитектурой сложной системы в целом с развитием получается беда быстрее, чем при развитии после проектирования. Хотя при проектировании тоже можно не угадать.
Большое спасибо за такие развернутые комментарии! Когда из этого буду делать доклады или другие материалы - обязательно учту наше обсуждение!
Если бизнес-заказчикам объяснять, что "вот эти объекты у нас будут во всех системах одинаковы" или "мы не будем поддерживать структуру объектов старой legacy-системы, у нас будет другая структура, и мы будем делать преобразования при интеграции" - понимают. Но да, важны объяснения в понятных им терминах. Это проблема, такая же как с диаграммами классов - она очень богатая, чтобы бизнес-заказчики ее понимали - надо использовать разумное подмножество, ограничивать себя. Иначе ты что-то нарисовал, и думаешь что объяснил важное, а они думают "ну, здесь какие-то непонятные значки, наверное техническое и неважное".
ERwin да, предлагал. Но это - уже проектирование БД, этап дизайна, а не бизнес-модели. А вот что модель предметной области должна быть целостной и непротиворечивой - учебники писали.
Потому что макеты интерфейсов не раскрывают структуру системы. Ты добавил на заказ в интерфейсах магазина поле "комментарий для курьера как проехать" или даже возможность подгрузить туда рисунок - а этого мало, еще надо протянуть через интеграцию через все системы до мобильного рабочего места курьера и там показать. Или сделал признак на заказе "отгружать по предоплате" - тоже надо учесть в алгоритмах, чтобы если предоплаты нет - склад не начинал собирать заказ и, главное, не отгрузил его. Куча прецедентов, когда про все эти связи забывали, а просто дорисовывали интерфейс.
Use case и user story - альтернативная история. В принципе это тоже требования - потому что система описывается как черный ящик.
Смотри, тут слева - модель деятельности в виде бизнес-процессов, а дальше - ее поддержка через workflow бизнес-объектов, реализованных в системе. То есть единая модель включает и предметную область и систему.
Вот смотри: сначала делаем бизнес-модель, потом из нее - требования (черный ящик), потом на их основе - дизайн. При этом требования - граница между работой бизнес-аналитика и системного аналитика, именно они сшивают модели. И именно поэтому к ним внимание, чтобы обеспечить посыл: "система, удовлетворяющая требованиям будет решать бизнес-задачу". А так - не работает. И сила DDD в том, что он три разных процесса объединил в работу с одной моделью. Напрямую прослеживая на основе модели, как такой софт будет поддерживать бизнес-процессы на требуемом уровне.
Да, мы тоже строили объектную модель предметной области через диаграммы классов UML с середины нулевых. Книги по DDD переведены позднее. Но на английском книга Эванса вышла в 2003.
Ну, да. Шаблон Business Objects был еще у Фаулера, и OOAD тоже в эту сторону работал. А параллельно развивались шаблоны, ориентированные чисто на структурирование кода - инъекции, фасады, фабрики. Проблема в том, что без них ты от Business Objects получал антипаттерн BigObject - потому что бизнес-объекты реально многообразны. А DDD предложил принцип: объекты предметной области должны прозрачно и единообразно отражаться в код. Не обязательно 1:1, это лишь самый простой способ. Можно для каждого делать DTO, контроллер, фабрику - но это должно быть единообразно. И наследование тоже можно реализовывать по-разному, но тоже единообразно.
Да, именно так: заказчикам процессные модели понятнее, чем онтологические, поэтому вместо онтологических моделей начали писать просто словарь понятий предметной области, и рисовать только процессы. А объекты появлялись уже только при проектировании приложения, в виде ER-схемы БД. Хотя был шаблон Business Object от Фаулера, который как раз говорил про использование модели предметной области как основе для проектирования объектов, что предполагало, что модель объектов мы все-таки создаем.
BPMN предполагает указание объектов и Archimate - тоже. Но без подробной проработки их структуры и атрибутов. А этого недостаточно.
Такие инструменты есть (из распространенных Enterprise Architect). Но при этом в таком режиме - с трассировкой требований, выявлением противоречий и т.п. - используются только в некоторых специальных областях с высоким требованием надежности, например, при проектировании бортового софта автомобилей (в современном автомобиле софт управляет не только автопарковкой, но и, например, тормозами - нет прямого привода от педали тормоза на колодки). Потому что сильно сложно и дорого.
Оба примера - требования, ни не раскрывают устройство системы. Модель возникает, например, когда описывается способ восстановления пароля. И дальше этот способ можно оценить с точки зрения безопасности: не сможет ли с его помощью злоумышленник получить доступ от имени конкретного пользователя, зная логин, но не зная пароля.
Аналогично про ширину колонок: сохранять настройки можно на локальном рабочем месте, или в настройках, связанных с логином пользователя (могут быть и другие варианты). В первом случае пользователь, войдя с другого компьютера все свои настройки теряет и наоборот, другой пользователь с того же компьютера получает чужие настройки. А во втором - будут сложности если пользователь работает с разных рабочих мест с разным разрешением экрана. В зависимости от того, насколько пользователю важна настройка внешнего вида таблицы сделок для его работы, могут быть разные решения.
Спасибо, учту на будущее. Потому что когда рассказываешь что-то с чем давно работаешь, не очевидно, что может быть непонятно. Попробую ответить.
Ограниченный контекст возникает из границ проекта. Сейчас прошло время больших монолитных систем, покрывающих какую-то предметной область. Собственно, оно давно прошло, все ERP - из крупных модулей. Но вот представления о том, что модель предметной области надо строить на всю область, с которой имеешь дело - осталось. А в результате ты разрабатываешь систему оптовых продаж, но она интегрируется с системами склада и ведения остатков, а в них работают не только с оптовыми продажами клиентам, но и с отгрузкой в розничные магазины, перевозками между складами и поставками. При этом эти системы в плане модернизации в перспективе может быть замена и этих систем тоже. И в результате аналитики пробовали построить модель оптово-розничной торговли целиком, задача получалась неподъемной. Или аналогично с банком или бухгалтерией - при проектировании главной книги пытались учесть все виды сделок, а их очень много. Выделение ограниченных контекстов позволяет с этим конструктивно работать. В том числе - не тянуть в модели для новых систем понятия, сформированные на основе старых, даже если с ними предусмотрена интеграция.
Почему объекты не подходят для описания работы с очередями? Потому что в них методы выполняются синхронно и результат обработки запроса гарантирован. В классических приложениях многое обеспечивали транзакции - у тебя был или успех, или откат при обработке запроса пользователя. Особая обработка возникала редко. А если у тебя асинхронная обработка на очередях, то там транзакции - в рамках обработки одного сообщения, инстанс может упасть, его работа откатится - а сообщения останутся и будут обработаны. И это - не внутреннее дело разработчика, многое из этого имеет бизнес-последствия, как минимум - вываливается на службу поддержки и это надо обсуждать со стейкхолдерами на понятном им языке. Модель акторов это позволяет. А классическая объектная модель перестает соответствовать реализации на сервисах, на ней эти ситуации обсуждать нельзя.
Но про модель акторов я в статье подробно не писал, это есть в докладе. на который ссылка. Возможно, в будущем напишу отдельную статью.
Но в данном случае у нас не алгебра, а разработка софта, и там моделью системы является представление, описывающее конструкцию системы, обычно в каком-то формализме. Например, в виде объектов, их атрибутов и методов. При этом атрибуты можно по смыслу сопоставить с отношениями, а методы - с операциями. Модель в ООП методы включает. Без них получаем только модель данных.
Требования - описание системы как черного ящика, без описания конструкции. Модель - описание устройства системы, ее работы.
У Эванса в книге язык создавался для проекта. Правда, там язык появлялся сразу, а концепция контекстов - довольно далеко. Но, я с ним согласен, потому что есть тезис: все члены проекта общаются на одном едином языке, это важно. Если проект включает несколько контекстов - значит язык их должен как-то включать все вместе. И если речь везде идет о Заказе покупателя - то там один Заказ. А если у нас есть Заказ покупателя в интернет-магазин и Заказ на доставку в транспортную компанию, то слово Заказ становится запрещенным, надо пояснять. Причина, почему язык один в том, что люди с громадным трудом переключаются между языками в ходе одной коммуникации. Путаница будет, не будут выдерживать. А то, что в разных контекстах для заказа покупателя могут быть важны важны разные атрибуты - понятно.
Вопрос о требованиях - это вопрос о границах проекта. потому что требование "Организация Х должна формировать и отправлять клиентам коммерческое предложение" можно реализовать вообще без софта, с использованием Word и электронной почты, а можно поддержать софтом в той или иной мере. Граница - очень подвижная. Основной смысл использования моделей, с моей точки зрения, в том, что они позволяют представить потенциал софта: какие решения поддержать просто, а какие - нет. А если функционал софта закрыт описанием через требования, как черный ящик, то это уже нельзя, и сплошь и рядом возникают проколы, когда бизнес требует сложные фичи, думая что это просто и наоборот, не просит удобного, не зная, что это можно несложно сделать.
Это вы не в курсе. Социократия - технология организации компаний, который работает не в малых группах, а на большом масштабе, на сотни человек точно и это проверено практикой. Это - не малые группы. И это - не мной изобретенная собственная технология, она развивается международным сообществом. И именно под таким названием - потому что в основа предложена Огюстом Контом как метод, масштабируемый на все общество. И оригинальный вариант даже пробовали в 19 веке применить в масштабах отдельно взятой страны - в Бразилии, но там не получилось. Впрочем, это - в прошлом, технология была переработана и адаптирована именно для управления компаниями, это первоначально сделали в Голландии. При этом ее можно брать не целиком, а использовать отдельные шаблоны для решения конкретных проблем. А в статье (как и в докладе), я фокусировался на тех шаблонах, которые могут быть интересны и полезны для ИТ-компаний.