Комментарии 27
позицию Backend-разработчика.
…
архитектурных навыков
А как для/у вас — архитектор это не выделенная персона, а размазанная по команде ответственность?
Тут я сошлюсь на Эрика Эванса, Agile-манифест и опыт авангардных группировок. Лучшая команда та, в которой все вносят вклад и отчасти да, архитекторы.
А как для/у вас — архитектор это не выделенная персона, а размазанная по команде ответственность?
То есть на каждом проекте есть выделенный архитектор. Круто. Как попасть в Вашу Вселенную?
То есть на каждом проекте есть выделенный архитектор
Где я такое писал? Я придерживаюсь мнения, что на одном проекте должен быть один архитектор за которым последнее слово- это да, иначе очень сложно согласовать систему. А почему его нет это вопрос уже к бизнесу. Может быть не считают нужным, может денег нет, а может и то и другое.
Если ответ на этот вопрос у вас вызывает затруднения, загляните в мой небольшой ЛикБез на тему.
Удивительно, что ответа в ЛикБезе так и нет.
Если предполагается асинхронное взаимодействие, а ответ не требуется — это идеальный случай использовать брокер сообщений.
Во-первых, это идеальный случай только тогда, когда вы можете легко развернуть этот самый брокер. А если нет, то вообще-то есть множество других способов сделать асинхронное взаимодействие, в том числе на REST (я вот делал, и на REST, и поверх SOAP, и как только не).
А во-вторых, внезапно, через брокер сообщений еще и ответ можно прислать.
Выбирая вид взаимодействия для остальных случаев, правильно будет принимать решение, исходя из организации доменной логики.
Не доменной логики, а выбранного API. А выбранный API должен определяться сценариями использования.
Не доменной логики, а выбранного API
Большинство людей считают также, и до кучи выделяют какую-то технологию, потому что она новее, ближе, испытанная временем — т.е. субъективно.
Подобное мнение ошибочно. Вам нужно выполнить задачу с помощью своего решения, а не найти для решения задачу. Вы же говорите API должен определяться сценариями использования. Эти же сценарии определяются и определяют логику предметной области.
Большинство людей считают также, и до кучи выделяют какую-то технологию, потому что она новее, ближе, испытанная временем — т.е. субъективно.
А при чем тут технология? Я говорю об API, которое является частью дизайна ПО, и о сценариях использования, которые предшествуют этому дизайну.
Подобное мнение ошибочно.
Какое конкретно мнение ошибочно, и почему?
lair я бы не хотел бы цитировать себя, особенно если вам это не нужно.
Дело в том, что если вы при проектировании исходите исключительно из "сценариев использования", т.е. потребностей внешних систем, вы определяете форму (API), игнорируя содержание (структуру доменной логики, зависимости). Лучше подойдёт тот кейс, который принесёт для решения единство API и внутренней организации.
Требования порождают иногда сначала форму, когда нужно связать что-то, что уже есть и имеет свою структуру, а иногда содержание, когда задача не связана с другими. Нет причин противопоставлять API логике приложения.
я бы не хотел бы цитировать себя, особенно если вам это не нужно.
То есть "подобное мнение" приведено вами, а не мной, правильно?
Дело в том, что если вы при проектировании исходите исключительно из "сценариев использования", т.е. потребностей внешних систем, вы определяете форму (API)
Я не говорил "исключительно". Я при проектировании исхожу из всего доступного набора требований.
То есть "подобное мнение" приведено вами, а не мной, правильно?
Я аргументировано объяснил свою позицию, привёл ссылки. Напишите ответную статью, рассмотрите кейс-другой который будет противоречить статье.
Пока что диалога не получается — с вашей стороны лишь отрицание.
А вот поверить просто так не могу.
Чему поверить-то?
Наше несогласие похоже в плоскости того что сначала — взаимодействия или частные решения. Я склоняюсь к тому, что совокупность ландшафта определяет форму взаимодействия, поэтому организовать API соответственно сложившимся системам логично.
Иначе вы предлагаете такое:
Я склоняюсь к тому, что совокупность ландшафта определяет форму взаимодействия
Что такое "совокупность ландшафта"?
организовать API соответственно сложившимся системам логично
Это когда у вас системы сложившиеся. А когда вы что-то новое делаете?
А с другой стороны, как раз когда у вас система сложившаяся, и в ней все взаимодействие уже на сообщениях, или уже на RPC — достаточно странно говорить о выборе: надо в первую очередь смотреть, вписывается ли оно в сложившуюся систему, а только потом — как делать, если не вписывается.
Иначе вы предлагаете такое:
Нет, я такое не предлагаю.
Напишите ответную статью, рассмотрите кейс-другой который будет противоречить статье.
Да вот вам простой кейс, даже статьи не заслуживает. Надо нам решить "простую" задачу распознавания документа. На входе — документ (pdf/jpg, короче говоря, "бумажка"), на выходе — он же в структурированном представлении (счет/чек/выписка/платежка, проще говоря, DTO).
Как организация доменной логики (т.е. того, как будет построено распознавание внутри сервиса, который за него отвечает) влияет на выбор "RPC vs REST vs MQ" для взаимодействия этого сервиса с его клиентами?
Если предполагается асинхронное взаимодействие, а ответ не требуется — это идеальный случай использовать брокер сообщений
lair я вот не настолько свободен чтобы без конца комментарии писать. Поэтому, наверное больше не стал бы отвечать. Мы читали вроде бы одни книги, а выводы сделали разные.
Когда вы говорите — я делаю так, потому что сначала сценарий, это значит вы всем удобной архитектор, который разметит стыки между разработчиками/аналитиками/заказчиками и пойдёт дальше строчить комментарии или делать другие дела, не связанные с проектированием.
Вместо этого, вам следует задуматься о том что у вас внутри, порисовать Context Map, а когда к вам придут в следующий раз что-то проектировать, не набросать согласно сценарию, а всё же спроектировать, подумать над тем как это будет оптимальнее.
Ваш пример — типовой сценарий веб роли — очень интересно, как вы обоснуете не использование здесь очереди. Или мне интересно как вы придёте к SAPовца/1Сникам, и обоснуете им REST-сервис.
Когда вы говорите — я делаю так, потому что сначала сценарий, это значит вы всем удобной архитектор, который разметит стыки между разработчиками/аналитиками/заказчиками и пойдёт дальше строчить комментарии или делать другие дела, не связанные с проектированием.
Нет, не значит. Это значит, что вы себе придумали такую картину меня (которая ничего общего с реальностью не имеет).
Ваш пример — типовой сценарий веб роли — очень интересно, как вы обоснуете не использование здесь очереди.
Очень просто: все потребители находятся за пределами инфраструктуры, и не имеют доступа ни к какой очереди. Им удобнее всего HTTP API, и они его и получат.
(И это ровно потому, что я спроектировал и подумал, как будет оптимальнее)
Смотрю на картинку "synchronous / asynchronous" и складывается впечатление, что вы путаете синхронный и асинхронный ввод/вывод с последовательным/параллельным выполнением
Во первых. Взаимодействие чего с чем? Внутри системы или с конечным потребителем? Протоколы не обязаны быть идентичными и могут серьезно отличаться даже между компонентами внутри системы.
Во вторых. Вы смешали все в кучу. Между rest/mq/rpc нет или.
rest — архитектурный стиль, концепция
mq — компонент общения между процессами/потоками
rpc — удаленный вызов функций/процедур в заданном формате
т.е., банально,mq — это очередь сообщений, она не производит вычислений, а организует отложенную обработку для некоторого иного процесса, который из этой очереди будет читать сообщения и возможно, всего лишь возможно, отправлять в нее результат работы.
rpc же выполняет некоторую полезную нагрузку и выдает результат.
В третьих, что действительно важно, это ответить на вопросы:
— какой канал связи должен быть между вашими компонентами: двунаправленный или однонаправленный (и в каких именно направлениях, что тоже очень важно)
— формат сообщений (рядом, на мой взгляд, имеет смысл поставить и тип, а не выделять отдельно): json, xml, brotobuf и т.д.
В четвертых, есть асинхронный/синхронный и последовательный/параллельный вариант исполнения (их вариации).
Простой пример. Вы можете наружу выставить REST/JSON, который транскодируется в GRPC, который отправляет данные на обработку в RabbitMQ, из которого некоторое приложение читает данные по требованию удаленной информационной системы, обрабатывает и отдает ей результат через RPC/SOAP, которая связывается с исходной системой через предоставленный REST/JSON и передает результат своей обработки всем новым клиентам, через эту самую очередь.
«Если вам необходимо спроектировать взаимодействие двух систем, в каких случаях вы выберете RPC, в каких REST, а в каких MQ?»
Отвечая на ваш вопрос: я выберу ровно то из этого, что необходимо для решения задачи в соответствии с требованиями к системе.
Парни, мне кажется это очередное произведение нейронки. Хотя я не программист.
Стандартный подход — оцениваем требования к синхронности, наличию ответов, скорости, нагрузке, многозвенности, гарантий доставки/обработки, параллельной обработке, безопасности. Оцениваем технологические ограничения (кто-то не умеет gRPC, иногда вообще только http и.т.д.), наличествующие готовые решения.
Исходя из этого выбираем наиболее подходящие решения, оцениваем стоимость разработки.
И на первом месте будет естественным образом архитектура взаимодействия и сценарии использования, а уж потом вырисуется REST/SOAP/WCF/gRPC/MQ/Sokets/Files/RPC/etc.
А у вас как-то получилось, что вы вытащили наружу кишки системы и выбираете наиболее удобный способ взаимодействия с ними.
В данной публикации пытался показать связь дизайна предметной логики и API. В абстрактном вопросе для собеседования "REST и SOAP: в каких ситуациях вы выберете один из этих подходов, а в каких другой?" я вижу именно такой ответ. И предлагаю его критически осмыслить читателю, если другого обдуманного нет.
Что до работы, я думаю, что плохо когда есть и внутренние противоречия (структура доменной логики входит в противоречие с API) и одновременно есть внешние противоречия, проявляющиеся в требованиях перечисленных вами (безопасность, технологии и т.п.). В случае когда внешних ограничений нет, в момент первоначального проектирования, считаю корректным исходить из внутренностей. Таким образом, "стандартный подход" учитывает лишь внешние отношения, которые важны, но ими всё не ограничивается.
В абстрактном вопросе для собеседования «REST и SOAP: в каких ситуациях вы выберете один из этих подходов, а в каких другой?»если вопрос был бы именно таким, я бы предпочёл рассуждения о связности систем, имеющихся ограничениях, сложностях реализации.
Например: soap «тяжелее» rest по объёму данных; требует сторонних библиотек, если клиент на js (без либы писать и разбирать запросы будет сложно); но, если сервер предоставляет wsdl, можно написать типизированного клиента; правда и для rest можно воспользоваться swagger и для просмотра api и для генерации клиента; а если вдруг и клиент и сервер — это модули нашей разработки, то логично было бы вынести описание апи в отдельную библиотеку, что уменьшит вероятность ошибок в реализации, и, при этом, если с обоих сторон js — проще делать rest, а если это бэк — то проще сделать soap.
При этом архитектурной разницы между этим типами api нет. Вы в статье пишете, что в одном из кейсов rest не подходит, но это выглядит как немотивированное требование к «чистоте» rest-api, но у этого требования очень низкий приоритет. А вот реализация идемпотентности никак не зависит от выбранного протокола.
Взаимодействия. RPC vs REST vs MQ