По меркам Китая они платят примерно вдвое выше рынка. Они называли конкретные цифры, и люди из принимающей стороны подтвердили, что это правда. В цифрах это выглядит так: зарплаты 500 тыс – 2 млн юаней в год, отпуска (10 дней в год, больничные, материнство - это в Китае хорошо), мед.страховка, питание в офисе, фитнес и медцентр в офисе, субсидия за аренду жилья (но небольшая, 2 тыс в месяц), служебное такси, компенсация за отношения на расстоянии (если муж в Пекине, а жена в Шанхае, то +3 тыс), развлечения (день питомцев, визит знаменитостей, клубы по интересам, ярмарки), другие социальные блага (все записано с голоса). 1 юань - около 12 рублей. Так что у компании нет проблем с наймом.
Да, сотрудник не владеет компанией. И он это понимает - и в Китае и везде.
Страх перед тем, что ИИ лишит всех работы приходит к нам с Запада. И фокус на проектах, которые позволят за счет ИИ сократить много рабочих мест - он тоже оттуда. То есть из тех мест, где рождаются (рождались?) самые современные модели. А доступ к моделям - он есть, с этим, по-моему, нет ни у кого проблемы.
Но, даже если принять вашу метафору, то пора детям становиться взрослыми. Не абы какими, а умными. Это само не происходит, а требует усилий. Статья - мой скромный вклад.
SDLC точно не описывает рост специалиста, это про проект, но картинка умозрительная, тут я согласен. И то, что нет правил и алгоритмов - тоже. Собственно, меня огорчает то, что многие верят в их существование и пытаются ими овладеть, вместо того, чтобы заниматься более полезными вещами. Поэтому и родилась статья, попытка объяснить.
А что касается вашего списка, то там до кода есть 1 - концептуальное описание. Которое должно убедить команду (если в разработке больше одного человека), а еще должно убедить владельца денег одобрить реализацию, если команда не будет делать это за свой счет в свободное время. И это - важная часть. Но потом - код, особенно если идея новая, тут я согласен.
Мне еще интересен пункт 3 про фиктивные требования. Он как-то наводит на мысли, что финансирование могут одобрить на одни цели, а фактически сделать другое, и надо закрыть разрыв. Или это обычные корпоративные игры, когда руководитель может санкционировать работу, но дальше ему нужны отчеты, что все было "по процессу"? Или имеется ввиду что-то другое?
Я о 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 - из крупных модулей. Но вот представления о том, что модель предметной области надо строить на всю область, с которой имеешь дело - осталось. А в результате ты разрабатываешь систему оптовых продаж, но она интегрируется с системами склада и ведения остатков, а в них работают не только с оптовыми продажами клиентам, но и с отгрузкой в розничные магазины, перевозками между складами и поставками. При этом эти системы в плане модернизации в перспективе может быть замена и этих систем тоже. И в результате аналитики пробовали построить модель оптово-розничной торговли целиком, задача получалась неподъемной. Или аналогично с банком или бухгалтерией - при проектировании главной книги пытались учесть все виды сделок, а их очень много. Выделение ограниченных контекстов позволяет с этим конструктивно работать. В том числе - не тянуть в модели для новых систем понятия, сформированные на основе старых, даже если с ними предусмотрена интеграция.
Почему объекты не подходят для описания работы с очередями? Потому что в них методы выполняются синхронно и результат обработки запроса гарантирован. В классических приложениях многое обеспечивали транзакции - у тебя был или успех, или откат при обработке запроса пользователя. Особая обработка возникала редко. А если у тебя асинхронная обработка на очередях, то там транзакции - в рамках обработки одного сообщения, инстанс может упасть, его работа откатится - а сообщения останутся и будут обработаны. И это - не внутреннее дело разработчика, многое из этого имеет бизнес-последствия, как минимум - вываливается на службу поддержки и это надо обсуждать со стейкхолдерами на понятном им языке. Модель акторов это позволяет. А классическая объектная модель перестает соответствовать реализации на сервисах, на ней эти ситуации обсуждать нельзя.
Но про модель акторов я в статье подробно не писал, это есть в докладе. на который ссылка. Возможно, в будущем напишу отдельную статью.
Но в данном случае у нас не алгебра, а разработка софта, и там моделью системы является представление, описывающее конструкцию системы, обычно в каком-то формализме. Например, в виде объектов, их атрибутов и методов. При этом атрибуты можно по смыслу сопоставить с отношениями, а методы - с операциями. Модель в ООП методы включает. Без них получаем только модель данных.
По меркам Китая они платят примерно вдвое выше рынка. Они называли конкретные цифры, и люди из принимающей стороны подтвердили, что это правда. В цифрах это выглядит так: зарплаты 500 тыс – 2 млн юаней в год, отпуска (10 дней в год, больничные, материнство - это в Китае хорошо), мед.страховка, питание в офисе, фитнес и медцентр в офисе, субсидия за аренду жилья (но небольшая, 2 тыс в месяц), служебное такси, компенсация за отношения на расстоянии (если муж в Пекине, а жена в Шанхае, то +3 тыс), развлечения (день питомцев, визит знаменитостей, клубы по интересам, ярмарки), другие социальные блага (все записано с голоса). 1 юань - около 12 рублей. Так что у компании нет проблем с наймом.
Да, сотрудник не владеет компанией. И он это понимает - и в Китае и везде.
Да, очень правильное замечание! Спасибо!
Страх перед тем, что ИИ лишит всех работы приходит к нам с Запада. И фокус на проектах, которые позволят за счет ИИ сократить много рабочих мест - он тоже оттуда. То есть из тех мест, где рождаются (рождались?) самые современные модели. А доступ к моделям - он есть, с этим, по-моему, нет ни у кого проблемы.
Но, даже если принять вашу метафору, то пора детям становиться взрослыми. Не абы какими, а умными. Это само не происходит, а требует усилий. Статья - мой скромный вклад.
SDLC точно не описывает рост специалиста, это про проект, но картинка умозрительная, тут я согласен. И то, что нет правил и алгоритмов - тоже. Собственно, меня огорчает то, что многие верят в их существование и пытаются ими овладеть, вместо того, чтобы заниматься более полезными вещами. Поэтому и родилась статья, попытка объяснить.
А что касается вашего списка, то там до кода есть 1 - концептуальное описание. Которое должно убедить команду (если в разработке больше одного человека), а еще должно убедить владельца денег одобрить реализацию, если команда не будет делать это за свой счет в свободное время. И это - важная часть. Но потом - код, особенно если идея новая, тут я согласен.
Мне еще интересен пункт 3 про фиктивные требования. Он как-то наводит на мысли, что финансирование могут одобрить на одни цели, а фактически сделать другое, и надо закрыть разрыв. Или это обычные корпоративные игры, когда руководитель может санкционировать работу, но дальше ему нужны отчеты, что все было "по процессу"? Или имеется ввиду что-то другое?
Я о 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 - из крупных модулей. Но вот представления о том, что модель предметной области надо строить на всю область, с которой имеешь дело - осталось. А в результате ты разрабатываешь систему оптовых продаж, но она интегрируется с системами склада и ведения остатков, а в них работают не только с оптовыми продажами клиентам, но и с отгрузкой в розничные магазины, перевозками между складами и поставками. При этом эти системы в плане модернизации в перспективе может быть замена и этих систем тоже. И в результате аналитики пробовали построить модель оптово-розничной торговли целиком, задача получалась неподъемной. Или аналогично с банком или бухгалтерией - при проектировании главной книги пытались учесть все виды сделок, а их очень много. Выделение ограниченных контекстов позволяет с этим конструктивно работать. В том числе - не тянуть в модели для новых систем понятия, сформированные на основе старых, даже если с ними предусмотрена интеграция.
Почему объекты не подходят для описания работы с очередями? Потому что в них методы выполняются синхронно и результат обработки запроса гарантирован. В классических приложениях многое обеспечивали транзакции - у тебя был или успех, или откат при обработке запроса пользователя. Особая обработка возникала редко. А если у тебя асинхронная обработка на очередях, то там транзакции - в рамках обработки одного сообщения, инстанс может упасть, его работа откатится - а сообщения останутся и будут обработаны. И это - не внутреннее дело разработчика, многое из этого имеет бизнес-последствия, как минимум - вываливается на службу поддержки и это надо обсуждать со стейкхолдерами на понятном им языке. Модель акторов это позволяет. А классическая объектная модель перестает соответствовать реализации на сервисах, на ней эти ситуации обсуждать нельзя.
Но про модель акторов я в статье подробно не писал, это есть в докладе. на который ссылка. Возможно, в будущем напишу отдельную статью.
Но в данном случае у нас не алгебра, а разработка софта, и там моделью системы является представление, описывающее конструкцию системы, обычно в каком-то формализме. Например, в виде объектов, их атрибутов и методов. При этом атрибуты можно по смыслу сопоставить с отношениями, а методы - с операциями. Модель в ООП методы включает. Без них получаем только модель данных.