Зависит от того направленный граф или нет. Я изначалько подразумевал направленный граф, но стрелочки загромождают схему. :) Поправлю схемы чуть позже... На суть это не сильно влияет.
Да, Гремлин весьма распространен в графовых БД. Однако у лидера этого класса БД (Neo4j) есть свой язык — Cypher. Мне он показался еще более удобным…
Но с производительностью использование диалекта связывать смысла не имеет. Важно что у вас за движок выполняет запросы. Но вот читабельность кода будет ясно выше, поэтому такие диалекты и изобретают.
Для матрицы смежности? Пробовали. Строго говоря подобного можно добиться оперируя битами в наборе числовых значений (если у вас не PostgreSQL). Вполне себе вариант. Но обвес кода нужно будет прилично так написать.
Не знаю почему. :) Согласен, что к выбору нужно подходить вдумчиво и никому не подражать. У графовых БД часто очень выразительный и удобный синтаксис написания запросов. Вместо 8 строчек с джойнами вы можете получить 1 строчку как аналог. Но средства диагностики, администрирования по своему развитию уступают реляционным. Поэтому поступаем как всегда — анализируем требования, в том числе не функциональные. И выбираем то, что лучше всего подходит для нашего проекта.
Давайте по порядку. Сам паттерн Strangler вполне применим при рефакторинге и монолита и вообще любого приложения. Это даже и на картинках у меня показано. Во-вторых. Я не считаю, что монолит всегда должен быть распилен на микросервисы. Это лишь один из способов. У него есть плюсы и минусы. Из минусов, например, высокие требования к развитию инфраструктуры... Но это тема для отдельной статьи. Тут, конечно, нужно упомянуть Kamil Grzybek и его Modular Monolith. Думаю загуглите, если не видели еще.
Версионирование агрегатов видимо подразумевает, что каждую новую версию вы гоняете по шине сообщений? Т.е. есть пользователь — у него меняется имя. И есть еще 100500 полей. Меняем имя — улетает вся версия целиком?
Ну а что вам принципиально даст рассмотрение этого варианта? СУБД вполне может и без индекса сделать JOIN. Да, с индексом быстрее. И да — это наиболее типовое использование. Но мы в таком случае получим разные примеры для C# и SQL. Людям мало работавшим с СУБД будет сложнее вникать — такие соображения у меня на этот счет.
Конечно так будет эффективнее. Но как, в таком случае, индекс будет выглядеть на С#? Дополнительный Dictionary? И тут мы понимаем, что опять же, это разные инструменты. И то, что в SQL делается в два счета — в C# нужно переписывать код.
Я, конечно, эксперементировал с индексами. Но предпочел не включать их в статью. В случае Nested Loop индекс даст прирост производительности на порядок. Он так и называется Index Nested Loop — когда для вложенного цикла используется индекс. Вообще вариаций у Nested Loop много — еще одна Block nested loop.
В случае с Hash Join прирост не будет столь большим… но проще поэксперементировать. Исходники я оставил, если у вас есть Postgre — дело одной минуты. Не более.
Здесь бы, конечно, поразбираться с конкретной системой. Возможно мне удалось бы переубедить вас что обьеденив 3 сущности мы не получим монолит. А быть может вы раскрыли бы все детали, которые просто невозможно раскрыть в рамках одного маленького сообщения и нашлось бы совсем иное применение.
Исходя из моей практике — не вижу места для Entity Service в микросервисной архитектуре. Всегда находится решение лучше… Если все обстоятельно взвесить.
Да, это из SOA. Суть статьи, конечно, не про Майкрософт вовсе… И даже не про SOA. Скорее про то что получается из Entity Service в микросервисной архитектуре и что получается при слепом следовании примерам из документации.
Ну ок… вот видите как нам пришлось погрузиться в конкретные бизнес процессы. И вопросов на самом деле только больше стало. Задам все таки последнию порцию вопросов. Исходя из того что и как я понял.
Почему бы вам не обьеденить Catalog+Item+Inventory в один сервис. Предоставив наружу все то же самое что они сейчас предоставляют и съэкономив при этом на их текущем взаимодействии. Ведь там наверняка и так транзакционность обеспечивается? Сейчас у вас если упадет Item, то Inventory и Catalog так и так лежать тоже будут, т.к. на него завязаны.
Вы путаете технологии и паттерны доменной логики. Агрегат вполне можно даже разместить в РСУБД (конечно это будет значительным извращением). Технологии в этой задаче вторичны — дело в парадигме декомпозиции.
Все таки они связаны, хоть и не явно… вы ведь сами в скобках пишите про то насколько это сложно с данной технологией…
В целом, как я и писал выше уже, меня точность формулировок и конкретные значения на графике мало интересуют. Больше важен инструмент общения между специалистами.
Формально это может быть так, что при проектировании очередного сервиса рассматриваются два варианта организации логики. Тогда можно было бы на графике для каждого из вариантов попробовать изобразить кривую. И сделать более взвешенный выбор.
В таком случае будет CRUD у Item или просто на Read в основной массе? Каково, на ваш взгляд, обоснование выделение отдельного микросервиса? Все таки это оверхэд как минимум по производительности…
Т.е. почему бы каталог и Item не обьединить в одни сервис? (на примере вашей картинки)?
Тогда понятно, что вы имели в виду. Согласен, DDD знать нужно — есть много по нему и русскоязычных источников. И очень хороших, к слову.
По сущностям — ссылка на сайте Майкрософт до сих пор висит, никто ее не удаляет. Это раз. У джавистов в спринге — то же самое. Так что пока ситуация сохраняется и пока эта англоязычная документация висит от лица таких крупных компаний — Entity Service еще не раз многим из нас встретится на практике… ;)
А не могли бы вы пояснить вашу мысль более развернуто? Как принято 5 лет спустя проектировать системы? Особенно, если это система в закрытом контуре и без облаков?
В целом время само по себе на вопросы не отвечают и до сих пор встречаются люди, которые не слышали про SOLID и DDD. И это нормально, всегда есть что обсудить.
Зависит от того направленный граф или нет. Я изначалько подразумевал направленный граф, но стрелочки загромождают схему. :) Поправлю схемы чуть позже... На суть это не сильно влияет.
Но с производительностью использование диалекта связывать смысла не имеет. Важно что у вас за движок выполняет запросы. Но вот читабельность кода будет ясно выше, поэтому такие диалекты и изобретают.
Давайте по порядку. Сам паттерн Strangler вполне применим при рефакторинге и монолита и вообще любого приложения. Это даже и на картинках у меня показано. Во-вторых. Я не считаю, что монолит всегда должен быть распилен на микросервисы. Это лишь один из способов. У него есть плюсы и минусы. Из минусов, например, высокие требования к развитию инфраструктуры... Но это тема для отдельной статьи. Тут, конечно, нужно упомянуть Kamil Grzybek и его Modular Monolith. Думаю загуглите, если не видели еще.
Я, конечно, эксперементировал с индексами. Но предпочел не включать их в статью. В случае Nested Loop индекс даст прирост производительности на порядок. Он так и называется Index Nested Loop — когда для вложенного цикла используется индекс. Вообще вариаций у Nested Loop много — еще одна Block nested loop.
В случае с Hash Join прирост не будет столь большим… но проще поэксперементировать. Исходники я оставил, если у вас есть Postgre — дело одной минуты. Не более.
Исходя из моей практике — не вижу места для Entity Service в микросервисной архитектуре. Всегда находится решение лучше… Если все обстоятельно взвесить.
Почему бы вам не обьеденить Catalog+Item+Inventory в один сервис. Предоставив наружу все то же самое что они сейчас предоставляют и съэкономив при этом на их текущем взаимодействии. Ведь там наверняка и так транзакционность обеспечивается? Сейчас у вас если упадет Item, то Inventory и Catalog так и так лежать тоже будут, т.к. на него завязаны.
Все таки они связаны, хоть и не явно… вы ведь сами в скобках пишите про то насколько это сложно с данной технологией…
В целом, как я и писал выше уже, меня точность формулировок и конкретные значения на графике мало интересуют. Больше важен инструмент общения между специалистами.
Формально это может быть так, что при проектировании очередного сервиса рассматриваются два варианта организации логики. Тогда можно было бы на графике для каждого из вариантов попробовать изобразить кривую. И сделать более взвешенный выбор.
Почитаем… ;)
Т.е. почему бы каталог и Item не обьединить в одни сервис? (на примере вашей картинки)?
По сущностям — ссылка на сайте Майкрософт до сих пор висит, никто ее не удаляет. Это раз. У джавистов в спринге — то же самое. Так что пока ситуация сохраняется и пока эта англоязычная документация висит от лица таких крупных компаний — Entity Service еще не раз многим из нас встретится на практике… ;)
В целом время само по себе на вопросы не отвечают и до сих пор встречаются люди, которые не слышали про SOLID и DDD. И это нормально, всегда есть что обсудить.