Комментарии 4
Что меня реально удивляет, а еще больше бесит, так это то что в таких статьях про архитекторов воды немножко больше чем 99%. Почему бы не описать конкретные архитектурные задачи и их решения? Причем желательно в плане: вот так сделали и это было плохо, потом переделали на это и стало легче?
Я регулярно задаю вопросы в одной группе архитекторов в Facebook и там мне практически никогда не отвечают. Задаю вопросы в личке и тоже тишина. Чем это обусловлено?
Что бы не быть голословным вот пример вопроса который я задавал:
Простой же вопрос, правда? Нормальный архитектор со стажем решал эту проблему уже много раз, знает что работает, а что нет. Почему бы не ответить?
На этот казалось бы простой вопрос мне так никто и не ответил.
И таких вопросов у меня куча. И решать их мне приходится в одиночку. Никто своим опытом не делится. А может и нечем делится?
Я регулярно задаю вопросы в одной группе архитекторов в Facebook и там мне практически никогда не отвечают. Задаю вопросы в личке и тоже тишина. Чем это обусловлено?
Что бы не быть голословным вот пример вопроса который я задавал:
Итак, предположим есть куча микросервисов. Один из них работает с юзерами. Предположим пришел новый сотрудник, мы сделали нового юзера. Как только это произошло, надо запустить кучу других процессов. Например: надо отправить нового сотрудника на Security Training, после этого ему можно дать доступ в сеть, выдать ему комп, создать аккаунт и все такое. Это мы сделаем через workflow. Но есть функционал, который можно направить в сервис прямиком. Например: вдруг выяснилось, что дата рождения была неправильно записана, надо ее просто изменить, просто тупо изменить данные в таблице. Итак, возникает такая маленькая проблемка: иногда нужно перехватывать вызовы к микросервису и стартовать workflow, а иногда можно и просто вызывать сервис. Где хранить эту логику? В настоящий момент смотрим в сторону Apache Camel. Есть другие варианты, альтернативы? Заранее спасибо.
Простой же вопрос, правда? Нормальный архитектор со стажем решал эту проблему уже много раз, знает что работает, а что нет. Почему бы не ответить?
На этот казалось бы простой вопрос мне так никто и не ответил.
И таких вопросов у меня куча. И решать их мне приходится в одиночку. Никто своим опытом не делится. А может и нечем делится?
Совершенно не претендую на то, чтобы быть опытным enterprise архитектором, но, быть может дело в том, что Ваш вопрос не совсем простой? (Например, потому, что он у вас возник).
Вообще, про ваш вопрос хотелось бы узнать больше контекста — потому что пока чувствуется некоторый месс — микросервисы, воркфлоу,… В каком вы технологическом стеке вообще? Какова текущая архитектура системы?
Для вопроса в вакууме кажется — что ваш юзер-сервис уже немножко перерос один сервис и требует быть разделенным на сервис, предоставляющий наружу атомарные операции с пользователями (создать/изменить/etc...) — другой сервис отвечает за создание воркфлоу для пользователя, третий — хранит логику достаточную для принятия решения о том для каких изменений запускать воркфлоу, а для каких жить напрямую. — он и выставляется наружу.
«Нормальный архитектор со стажем решал эту проблему уже много раз» — Неа. Не решал ее нормальный архитектор. Другие задачи решал, а конкретно эту задачу не решал абстрактный нормальный архитектор. Ну вот не свезло ему.
P.S. Понимаю Вашу проблему в целом — отсутствие внешнего комьюнити. Хотя бы просто потому что архитектурные вопросы требуют серьезного погружения в тему каждый раз, когда возникают — а это — лень, да и времени жалко. Но тут как и везде — не хватает комьюнити — создай его :-)
Вообще, про ваш вопрос хотелось бы узнать больше контекста — потому что пока чувствуется некоторый месс — микросервисы, воркфлоу,… В каком вы технологическом стеке вообще? Какова текущая архитектура системы?
Для вопроса в вакууме кажется — что ваш юзер-сервис уже немножко перерос один сервис и требует быть разделенным на сервис, предоставляющий наружу атомарные операции с пользователями (создать/изменить/etc...) — другой сервис отвечает за создание воркфлоу для пользователя, третий — хранит логику достаточную для принятия решения о том для каких изменений запускать воркфлоу, а для каких жить напрямую. — он и выставляется наружу.
«Нормальный архитектор со стажем решал эту проблему уже много раз» — Неа. Не решал ее нормальный архитектор. Другие задачи решал, а конкретно эту задачу не решал абстрактный нормальный архитектор. Ну вот не свезло ему.
P.S. Понимаю Вашу проблему в целом — отсутствие внешнего комьюнити. Хотя бы просто потому что архитектурные вопросы требуют серьезного погружения в тему каждый раз, когда возникают — а это — лень, да и времени жалко. Но тут как и везде — не хватает комьюнити — создай его :-)
В каком вы технологическом стеке вообще?
это не важно. Принимаются любые варианты.
Какова текущая архитектура системы?
Микросервисная, со всеми вытикающими…
«Нормальный архитектор со стажем решал эту проблему уже много раз» — Неа. Не решал ее нормальный архитектор. Другие задачи решал, а конкретно эту задачу не решал абстрактный нормальный архитектор. Ну вот не свезло ему.
Описанная проблема — стандартная задача в любой мало-мальски большой системе.
Для вопроса в вакууме кажется — что ваш юзер-сервис уже немножко перерос один сервис и требует быть разделенным на сервис, предоставляющий наружу атомарные операции с пользователями (создать/изменить/etc...) — другой сервис отвечает за создание воркфлоу для пользователя, третий — хранит логику достаточную для принятия решения о том для каких изменений запускать воркфлоу, а для каких жить напрямую. — он и выставляется наружу.
Все так и есть. Ваш «третий» и есть то самое о чем я спрашиваю.
Но тут как и везде — не хватает комьюнити — создай его :-)
Группа на Facebooke вроде как уже коммунити, зачем изобретать велосипед?
Но все равно спасибо.
Я регулярно задаю вопросы в одной группе архитекторов в Facebook и там мне практически никогда не отвечают.
люди снимают
видеоклипы
очень занятыP.S.
EPAM остановись!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Из разработчиков — в Solution Architects: история одной трансформации