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