SB
ты просто физически не можешь весь датафлоу нарисовать.
Size: a a a
2020 September 07
R
Если на уровне процессов и команд хаос, то да
R
Если каждая команда занимается выделенной частью домена, то такую же диаграмму строишь сначала на уровне команд
R
ну и при таком количестве народу таки должен быть архикектор какой-нить, у которого есть виденье всей картины (пускай и не самое глубокое)
SB
ну у тебя мультики в голове. в идеале я с тобой согласен. но по факту таким системам обычно по 4-5+ лет, некоторым их частям, некоторым - полгода. и они не задокументированы настолько хорошо, и документация часто просто неактуальна и/или не учитывает транзитивные зависимости и рейскондишены.
SB
и единственное что ты можешь сделать в разумные сроки, чтобы работало и не будило тебя по ночам - энфорсить айди транзакции и стейтмашину поверх этого.
R
с тем, что обычно в таких системах хаос и разруха я согласен, а с тем, что по-другому невозможно сделать — нет.
AH
в моем случае было порядка 15 команд. это было нереально.
ну вот в моём случае было и локально на 3 команды и глобально на 15.
Глобально на 15 там костыли и ад, да.
Но мы, не поверишь, идём к тому чтобы их убрать!
Локально на 3 команды мы проектируем так чтобы костылей не было и этим залупам, которые всех заебали, отводится много времени на дизайн ревью
Глобально на 15 там костыли и ад, да.
Но мы, не поверишь, идём к тому чтобы их убрать!
Локально на 3 команды мы проектируем так чтобы костылей не было и этим залупам, которые всех заебали, отводится много времени на дизайн ревью
VK
оффтоп,
работал кто с BPM и подрубал веб апи?
есть какие-то хорошо либы бесплатные?
есть ли какие-то подводные камни?
у меня есть веб сервис с АПИ и в целом из набора апи этих можно выстраивать разные флоу.
Вот думаю как лучше это делать.
работал кто с BPM и подрубал веб апи?
есть какие-то хорошо либы бесплатные?
есть ли какие-то подводные камни?
у меня есть веб сервис с АПИ и в целом из набора апи этих можно выстраивать разные флоу.
Вот думаю как лучше это делать.
Бпмн это нотация если что
AH
Потому что когда данные текут в обе стороны и нет явного источника истины, неясно кто кого должен синхронизировать. Это всех порядком заебало
SB
с тем, что обычно в таких системах хаос и разруха я согласен, а с тем, что по-другому невозможно сделать — нет.
чтобы сделать по-другому нужен очень сильный и крепкий архитектор, до ахуя прозрачные и налаженные процессы коммуникации (на уровне хороших диаграм, стейтмашин, а не просто ссанина на плохом английском в тикетах Джиры), высокая инижерная в целом в команде, включая менеджеров.
SB
по пальцам пересчитать даже крупные продуктовые компании со штатом больше 100 человек, которые на такое хотя бы в теории способны.
AH
особенно потому что усложняет жизнь всех
Типа я создал ЧТО-ТО, надо узнать есть ли это что-то У НИХ
О, есть - создаём связь!
О, нет - надо им сообщить чтобы создали!
А когда те создадут, они нотифируют нас о том что они тоже создали ЧТО-ТО и надо нам упрочить этот кусок говна связью между нашими системами.
А уж на удалении сколько ебени
Типа я создал ЧТО-ТО, надо узнать есть ли это что-то У НИХ
О, есть - создаём связь!
О, нет - надо им сообщить чтобы создали!
А когда те создадут, они нотифируют нас о том что они тоже создали ЧТО-ТО и надо нам упрочить этот кусок говна связью между нашими системами.
А уж на удалении сколько ебени
SB
по пальцам пересчитать даже крупные продуктовые компании со штатом больше 100 человек, которые на такое хотя бы в теории способны.
и даже те, которые могут себе это позводить в 2/3 случая посчитают че почем и поймут, что это экономически не выгодно.
AH
Я думаю, у нас 90% проблем из-за залуп в потоке данных.
AH
Потому что это всё усложняет системы экспоненциально
AH
все делают одни и те же костыли чтобы их конкретный участок не пал смертью храбрых от лавины сообщений и делают миллиард костылей для распределенных транзакций чтобы всех синхронизировать на любом своём чихе