Очень понравилась статья. Однако, поставить "лайк" не хватает кармы.
Господа, подскажите, пожалуйста, какие архитектурные паттерны или методологии используете при формализации входящих требований для того, чтобы на выходе получилось информация, которую можно отдать аналитику для постановки задач программисту?
На работе дали задание описать текущий бизнес-процесс обработки запроса пользователя, который состоит из более чем 20 крупных шагов (которые декомпозируются до 80 мелких шагов) и нескольких тысяч строк кода, располагающегося в разных компонентах системы. Требуется:
а) описать текущий механизм работы кода,
б) описать новый бизнес-процесс, который должен быть похож на имеющийся, но будет отличаться обработкой других видов документов и будет предназначаться для передачи документов в другую систему, отличную от используемой сейчас,
в) предложить архитектурное решение, оптимальное по срокам, сложности и по возможности переиспользует максимум текущего кода.
Как это всё можно описать? С помощью каких диаграмм и нотаций, чтобы было с одной стороны и понятно, а с другой стороны чтобы не было перегруза информации на диаграммах? Использовать sequence? Но на этих sequence вообще будет мешанина из-за множества вызовов и множества кода, участвующего в процессе. И сами эти sequence долго рисовать.
С4 не подойдёт, так как она слишком высокоуровневая. Нужна с одной стороны детализация, с другой стороны возможность словами описать бизнес-процесс, дополнить.
Мне видится путь:
Рисовать в draw.io BPMN как старого так и нового бизнес-процесса (2 закладки на сайте draw.io), показать дельту
С целью типизации передаваемых/принимаемых данных сервисами, а также с целью пояснения хода бизнес-процесса написать текстовый документ, где порядковый номер шага бизнес-процесса будет соответствовать номеру "квадратика" на схеме BPMN.
С целью получения фактуры для аналитика с целью постановки задачи программисту нужно нарисовать структурную схему, указывающую, какие добавились/изменились классы или сервисы.
Описать требуемый к реализации функционал словами (ФТ + НФТ требования)
Прошу подсказать, а как будет реализовывать разработка нового функционала, если бизнес хочет использовать модную идеологию feature tag? Если включить одну фичу в одном сервисе, то это затрагивает изменения и в куче других сервисах-системах. Так? Значит, feature tag намного легче и быстрее, легитимнее использовать исключительно в монолите? Потому что можно включить эту фичу в одном месте и проконтролировать работу по всему монолиту сразу.
Второй вопрос - как сделать балансировку нагрузки на монолит, если он не позволяет этого реализовать? Грубо говоря, в монолит приходят данные и он (монолит) их обрабатывает и складывает в свою БД. Нельзя же обработать запрос "по частям", так как если поставить рядом второй монолит, то он просто перезатрёт в БД те данные, которые должен позже сохранить первый монолит. Значит, балансировку нагрузки летитимнее, проще и надёжнее делать исключительно с помощью атомарных микросервисов, у каждого из которых будет своя БД.
Как в идеологии микросервисов и монолитов уживаются Data lake (Озёра данных)? Под озёрами данных подразумеваю данные, на основании которых строится аналитика, прогнозы сбыта или делается отчётность. Если использовать микросервисы, то чтобы собрать с разрозненных БД всю цепочку информации о заказе, пункте выдачи (куда нужно привезти заказ) и информацию о платежах, скидках, потребуется опросить множество разных сервисов. Значит, для целостности данных и для их надёжной консистенции необходимо использовать монолит + одну-две базы под монолит?
Я тоже не понял. Если можно, расскажите, пожалуйста, в двух словах.
Очень понравилась статья. Однако, поставить "лайк" не хватает кармы.
Господа, подскажите, пожалуйста, какие архитектурные паттерны или методологии используете при формализации входящих требований для того, чтобы на выходе получилось информация, которую можно отдать аналитику для постановки задач программисту?
На работе дали задание описать текущий бизнес-процесс обработки запроса пользователя, который состоит из более чем 20 крупных шагов (которые декомпозируются до 80 мелких шагов) и нескольких тысяч строк кода, располагающегося в разных компонентах системы. Требуется:
а) описать текущий механизм работы кода,
б) описать новый бизнес-процесс, который должен быть похож на имеющийся, но будет отличаться обработкой других видов документов и будет предназначаться для передачи документов в другую систему, отличную от используемой сейчас,
в) предложить архитектурное решение, оптимальное по срокам, сложности и по возможности переиспользует максимум текущего кода.
Как это всё можно описать? С помощью каких диаграмм и нотаций, чтобы было с одной стороны и понятно, а с другой стороны чтобы не было перегруза информации на диаграммах? Использовать sequence? Но на этих sequence вообще будет мешанина из-за множества вызовов и множества кода, участвующего в процессе. И сами эти sequence долго рисовать.
С4 не подойдёт, так как она слишком высокоуровневая. Нужна с одной стороны детализация, с другой стороны возможность словами описать бизнес-процесс, дополнить.
Мне видится путь:
Рисовать в draw.io BPMN как старого так и нового бизнес-процесса (2 закладки на сайте draw.io), показать дельту
С целью типизации передаваемых/принимаемых данных сервисами, а также с целью пояснения хода бизнес-процесса написать текстовый документ, где порядковый номер шага бизнес-процесса будет соответствовать номеру "квадратика" на схеме BPMN.
С целью получения фактуры для аналитика с целью постановки задачи программисту нужно нарисовать структурную схему, указывающую, какие добавились/изменились классы или сервисы.
Описать требуемый к реализации функционал словами (ФТ + НФТ требования)
Правильно ли я думаю?
@sergey_prokofiev,@Dhwtj
Прошу подсказать, а как будет реализовывать разработка нового функционала, если бизнес хочет использовать модную идеологию feature tag? Если включить одну фичу в одном сервисе, то это затрагивает изменения и в куче других сервисах-системах. Так? Значит, feature tag намного легче и быстрее, легитимнее использовать исключительно в монолите? Потому что можно включить эту фичу в одном месте и проконтролировать работу по всему монолиту сразу.
Второй вопрос - как сделать балансировку нагрузки на монолит, если он не позволяет этого реализовать? Грубо говоря, в монолит приходят данные и он (монолит) их обрабатывает и складывает в свою БД. Нельзя же обработать запрос "по частям", так как если поставить рядом второй монолит, то он просто перезатрёт в БД те данные, которые должен позже сохранить первый монолит. Значит, балансировку нагрузки летитимнее, проще и надёжнее делать исключительно с помощью атомарных микросервисов, у каждого из которых будет своя БД.
Как в идеологии микросервисов и монолитов уживаются Data lake (Озёра данных)? Под озёрами данных подразумеваю данные, на основании которых строится аналитика, прогнозы сбыта или делается отчётность. Если использовать микросервисы, то чтобы собрать с разрозненных БД всю цепочку информации о заказе, пункте выдачи (куда нужно привезти заказ) и информацию о платежах, скидках, потребуется опросить множество разных сервисов. Значит, для целостности данных и для их надёжной консистенции необходимо использовать монолит + одну-две базы под монолит?