Хотелось бы уточнить что мешает совместить раздел Системного поведения и критериев приёмки? По сути, если проблема лежала именно в сфере "обнаружили баги" и это очевидно "баги постановки" это говорит о том что критерии приёмки недостаточно прописаны. В приведённом вами примере критерии приёмки выполняют роль некоего рудимента, о котором необходимо помнить, но в который никто не смотрит, поскольку все очевидно из BR и FR.
И ещё вопрос: ведёте ли вы отдельно базу BR и FR? Опять же из текущего примера не совсем понятно, поскольку везде используется один номер задачи 123, что оставляет за кадром проблему выявления неполноты требований, их перекрестного влияния и разрастания такой базы до размеров, когда с ней становится невозможно работать.
Спасибо за очень интересную и подробную статью. Подскажите пожалуйста, что именно Вы подразумеваете под "зона ответственности компоненты" и как определяете в документации? Интересно также из вашего опыта, как сотрудники, не являющиеся архитекторами/ аналитиками и не знающие решения целиком, справляются с определением зон ответственности отдельных сервисов?
Ну архитектур гораздо больше чем две (например кто-то счастлив на SOA, кто-то для MVP использует бессерверную) и в статье говорится собственно не о преимуществах монолита над микросервисами или наоборот, а о том когда стоит выбирать микросервисы, то есть какие основные предпосылки должны вас толкнуть к мысли в принципе задуматься о микросервисах, как об альтернативе. И о проблемах с ACID в статье также говорится, собственно как об одном из рисков при выборе именно микросервисного решения и упоминается SAGA как возможный путь решения, хотя на самом деле пути решения этим не ограничиваются.
Определенно не хотела становиться на путь инфоциганства, поскольку не имею цели никому ничего продавать, просто хотелось поделиться мыслями и вопросами, которые возникали у меня самой по этому поводу. И к сожалению я очень мало находила ответов, которые касались бы именно выгод или потерь с точки зрения бизнеса от внедрения микросервисов. В основном это действительно сравнение плюсов и минусов без указания на то, зачем собственно производится сам выбор. Поэтому именно последнее я и постаралась осветить)
И в любом случае спасибо за замечание, в следующий раз постараюсь писать более конкретно.
Добрый день, статья для меня очень интересная, потому что как раз перекликается с двумя проектами быстрой автоматизации, которыми я занималась на досуге.
Действительно если система позволяет сочетать таблицы, фильтры и представления, а также генерировать отчёты на основании этих таблиц, то прототип решения для автоматизации бизнес-процессов создаётся буквально за один день и позволяет выявить все узкие места и недопонимания, а также в некоторых случаях логические ошибки непосредственно на рабочих сессиях обсуждения с пользователем.
От себя могу порекомендовать присмотреться к таким примерам как notion, coda, сочетание google форм и таблиц для того чтобы определить направление развития своего движка.
От себя могу кратко перечислить недостатки прототипирования на таблицах, с которыми я столкнулась на практике:
очевидная реляционная логика, которая кажется естественной аналитику, очень трудно доходит до заказчика, поэтому если ваша доменная область состоит из нескольких сущностей рекомендую дополнительно любым способом визуализировать связи между ними или обеспечить визард, который проведет заказчика по трудному пути выбора характера и направления связи.
табличная форма интерфейсов рано или поздно наталкивается на проблемы отображения: необходимо заводить возможности контекстного сокрытия полей в зависимости от роли, статуса, и т.д. либо, что гораздо проще, позволить заказчику тиражировать представления с произвольным набором полей и давать доступ целиком к представлению по роли и статусу. Вторая проблема представления: это проблема избытка полей и взаимосвязанная с ней проблема дизайна. Заказчик не дизайнер и для него нужны шаблоны форм. Кода дает такую возможность, но к сожалению не даёт возможности самостоятельной настройки шаблонов.
настройка пути по статусам превосходно сделана в Jira и вполне возможно заимствовать их опыт, то же касается настройки ролей. Но имхо этот пункт уже уходит за пределы быстрого прототипирования. Однако вы еще можете приглядеться к СЭД где эту проблему решают давно.
В целом однако все равно остаётся проблема реинжиниринга бизнес-процессов и выявления узких мест, которую можно попытаться наглядно решить только имитацией потока элементов, операций бизнес-процесса и такие примеры тоже есть и реализованы как раз для BPMN, но никто не мешает вам загрузить подобным же образом Workflow движок, главное обозначить граничные условия процессов.
А в целом очень интересное начинание.
Спасибо за то что поделились опытом.
У меня есть два вопроса:
Хотелось бы уточнить что мешает совместить раздел Системного поведения и критериев приёмки? По сути, если проблема лежала именно в сфере "обнаружили баги" и это очевидно "баги постановки" это говорит о том что критерии приёмки недостаточно прописаны. В приведённом вами примере критерии приёмки выполняют роль некоего рудимента, о котором необходимо помнить, но в который никто не смотрит, поскольку все очевидно из BR и FR.
И ещё вопрос: ведёте ли вы отдельно базу BR и FR? Опять же из текущего примера не совсем понятно, поскольку везде используется один номер задачи 123, что оставляет за кадром проблему выявления неполноты требований, их перекрестного влияния и разрастания такой базы до размеров, когда с ней становится невозможно работать.
Спасибо за очень интересную и подробную статью. Подскажите пожалуйста, что именно Вы подразумеваете под "зона ответственности компоненты" и как определяете в документации? Интересно также из вашего опыта, как сотрудники, не являющиеся архитекторами/ аналитиками и не знающие решения целиком, справляются с определением зон ответственности отдельных сервисов?
Определенно не хотела становиться на путь инфоциганства, поскольку не имею цели никому ничего продавать, просто хотелось поделиться мыслями и вопросами, которые возникали у меня самой по этому поводу. И к сожалению я очень мало находила ответов, которые касались бы именно выгод или потерь с точки зрения бизнеса от внедрения микросервисов. В основном это действительно сравнение плюсов и минусов без указания на то, зачем собственно производится сам выбор. Поэтому именно последнее я и постаралась осветить)
И в любом случае спасибо за замечание, в следующий раз постараюсь писать более конкретно.
Добрый день, статья для меня очень интересная, потому что как раз перекликается с двумя проектами быстрой автоматизации, которыми я занималась на досуге.
Действительно если система позволяет сочетать таблицы, фильтры и представления, а также генерировать отчёты на основании этих таблиц, то прототип решения для автоматизации бизнес-процессов создаётся буквально за один день и позволяет выявить все узкие места и недопонимания, а также в некоторых случаях логические ошибки непосредственно на рабочих сессиях обсуждения с пользователем.
От себя могу порекомендовать присмотреться к таким примерам как notion, coda, сочетание google форм и таблиц для того чтобы определить направление развития своего движка.
От себя могу кратко перечислить недостатки прототипирования на таблицах, с которыми я столкнулась на практике:
В целом однако все равно остаётся проблема реинжиниринга бизнес-процессов и выявления узких мест, которую можно попытаться наглядно решить только имитацией потока элементов, операций бизнес-процесса и такие примеры тоже есть и реализованы как раз для BPMN, но никто не мешает вам загрузить подобным же образом Workflow движок, главное обозначить граничные условия процессов.
А в целом очень интересное начинание.