Да, у нас одна команда так и сделала. Надеюсь, выложат в опенсорс в следующем году. Наверняка есть решения и от других крупных компаний, т.к. довольно часто требуется некий быстрый и надежный оркестратор для какой-то сложной логики
Мне больше нравится подход, когда база данных - такой же внешний сервис для нашего приложения, как и все другие. И тогда "классическая" ORM становится не нужна, нужен просто слой который правильно мапит доменные объекты в дтошки и правильно ими обменивается с базой. Hibernate в таком варианте использования приносит много дополнительной сложности
Меня наоборот работа "в реальном мире" только бесит. Вот ты покрасил условный забор, и где-то уже под конец поторопился и слишком краски налячкал. И теперь каждый раз на это смотришь и чувство прекрасного где-то внутри матерится. А отрефакторить перекрасить - уже сложнее, чем с нуля покрасить, т.к. старый слой краски будет все равно из под нового объемно выделяться. Либо все отчищать от старой краски, либо вообще весь забор выкидывать к чертям. На сколько ко же приятнее и спокойнее на работе, где из гита на любое место в истории вернулся и продолжил заново...
Помимо названного еще смущает то, что у 7-ки есть откровенные сложности с производительностью при параллелизации выполнения задач. Ну и нам хотелось иметь нечто типа SaaS решения, и на сколько я знаю, 7-ка тоже так может, но со множеством всяких "но"
По сравнению с камундой там много чего не хватает. Например, нет возможности весь процесс посмотреть, когда он еще в работе. Меньше возможностей вручную что-то делать с упавшим/зависшим процессом. Ну и, в принципе, когда речь про бизнесовые процессы, то там часто их аналитики рисуют, а с темпоралом это уже не реально )
Все от задач зависит. Для оркестрации наших бэкендовских задач темпорал вполне хорош. Но вот соседней команде для автоматизации бизнесовых процессов он уже не подходит. Они на 7-ю камунду решили вернутся, в надежде что коммьюнити продолжит багфиксы делать после EoL.
Ну тут вопрос упирает в уровень паранойи. База данных, по сути, тоже стороннее решение. У каждой системы есть свои особые кейсы, когда она может нарушать заявленные гарантии. Вчера, например, открыл для себя, что Kafka не дает 100% гарантии порядка записей в рамках ключа партиционирования. Как обычно, везде свои трейд-офы, главное об этом не забывать и заранее учитывать
Всегда идет выбор между тем - "оверинжинирить" или положить в тех.долг. И тут основной вопрос - что дороже. Например, про интерфейсы частый посыл - когда появится вторая реализация, тогда и сделаем. В такой трактовке кажется действительно дешевле положить это в тех.долг, т.к. неизвестно, когда это потребуется, и исправление выглядит совсем дешевым. Но интерфейсы это не только про наследование и разные имплементации. Интерфейсы еще позволяют описать API некоего блока кода и защититься от использования внутрянки этого кода снаружи. Вот если в таком случае не выставить заранее интерфейс, то потом, когда у вас появится еще один "потребитель" (а это частая история, в отличии от другой имплементации), никто не вспомнит про выделение интерфейса и система начнет превращаться в лапшу (те самые cohesion and coupling нарушаются). И тогда тех.долг становится очень дорогим (порой проще с нуля все переписать, чем распутать все переплетения в системе). Аналогично и с другими примерами статьи. Надо оценивать стоимость оверинжиниринга и стоимость тех.долга. Тот же однострочный метод с вызовом другого метода ("middle man"), что дешевле - сделать его сейчас (и иметь лишний переход при дебаге и в стектрейсах), или рефакторить когда потребуется добавить дополнительную логику в него с учетом особенностей использования всеми его потребителями. Каждый раз стоит об этом задуматься: а не делать на автомате то, что написали в книжке, или в статье из интернета. Чаще всего, многие вещи в книжках как раз написаны для того, чтобы при написании больших сложных систем сделать чуть больше работы, но зато обеспечить себе более дешевое развитие и изменение этой системы. Если у вас вся сложность системы заранее разбита на понятные блоки в виде простых микросервисов, то вы этот "оверинжиниринг" уже проделали заранее и нет смысла его еще и в код тащить (хотя в этом случае, я бы вообще задумался - а зачем вам там java)
Все равно потом может начать в тимлидство выносить. Уже сознание немного иначе работает, чем у рядового разработчика, на проблемы чуть иначе смотришь, и люди это помечают и тебя начинают снова в тимлидство подталкивать. Либо у самого может начаться ностальгия. В западных компаниях есть возможность тудя-сюда перемещаться. А вот в российских что-то пока встречал только возможность лишь в одну сторону двигаться
Завязывать доменную модель приложения на схему базы данных - странное решение. Получается, мы нюансы хранения данных тащим в бизнес логику. А без такого подхода Hibernate не будет работать.
Т.е. мне сама идея ORM, где схема данных матчится 1 к 1 в бизнес сущности приложения, кажется нарушением DDD, Clean Architecture и проч.
мой изначальный посыл как раз и был, что рич модель в ООП как раз и заставляет сначала подумать о дизайне. Ведь очевидно, когда в бизнес сущность Курс тащишь сервис для отправки email - это дикость. А вот в анемичной модели в CourseService затащить EmailService - вполне нормальное решение. Хотя по сути, это одно и тоже - нарушение границ контекста и смешивание уровней абстракции
Бизнес‑требования есть и к операциям, которые не меняют бизнес‑сущность
...
Ну то есть у вас логика раскидана по разным частям системы, другой программист не может просто открыть код покупки курса и сказать, отправляется в нем email или нет.
Прежде чем писать код, сначала было бы не плохо "причесать" бизнес требования и выстроить архитектуру системы. DDD тут в помощь. Когда из-за упавшего почтового сервиса у вас пользователи не смогут курс оплатить - я думаю, не очень хороший бизнес сценарий.
Так с логикой в сервисах все то же самое - все методы действий с сущностью можно поместить в один класс сервис
Да, но нет. Анемичная модель никак не может запретить менять состояние сущности из любого места в обход API, предоставленного сервисом. Если с кодом работает больше одного человека, то рано или поздно это произойдет. Плюс в сервисах возникает большой соблазн добавлять зависимости на другие сервисы и ответственность этого сервиса начинает сильно разрастаться (со всеми последствиями нарушения single responsibility).
Ну то есть у вас толстые контроллеры, которые управляют сохранением сущностей.Что если надо сделать то же действие в консольной команде, будете копипастить код контроллера?
А если у вас в контроллере происходит маппинг сущности, которую сервис вернул в DTO ответа - это толстый контроллер, или еще нет? В простых ситуациях я могу и в контроллере оставить связывание разных слоев приложения воедино. В более сложных это логично выносить на новый уровень абстракции (как и в ситуации, когда повялется другая точка входа, типа консольной команды)
У меня есть статья на эту тему с примером бизнес-требований
Вот как раз подобный код (правда на Java) я и вижу чаще всего в легаси проектах. Его легко писать, но поддерживать и развивать его очень трудно. Автор статьи, которую мы обсуждаем, очень пропагандирует использование конечных автоматов, так вот задача из вашей статьи идеально ложиться на стейт-машину. И это снимает проблему блокировок, упрощает валидацию и т.д. Собственно ваша статья как раз показывает, когда ООП анемичная модель определила архитектуру вашего решения.
Да, у нас одна команда так и сделала. Надеюсь, выложат в опенсорс в следующем году. Наверняка есть решения и от других крупных компаний, т.к. довольно часто требуется некий быстрый и надежный оркестратор для какой-то сложной логики
а сколько параллельных процессов на YDB удается обрабатывать?
postgres при 3-4К начинает затыкаться, думаем на что переходить - касандру или ydb
если единицы миллисекунд, то тогда это не про темпорал. Он слишком много сетевых взаимодействий делает
Мне больше нравится подход, когда база данных - такой же внешний сервис для нашего приложения, как и все другие. И тогда "классическая" ORM становится не нужна, нужен просто слой который правильно мапит доменные объекты в дтошки и правильно ими обменивается с базой. Hibernate в таком варианте использования приносит много дополнительной сложности
Меня наоборот работа "в реальном мире" только бесит. Вот ты покрасил условный забор, и где-то уже под конец поторопился и слишком краски налячкал. И теперь каждый раз на это смотришь и чувство прекрасного где-то внутри матерится. А
отрефакторитьперекрасить - уже сложнее, чем с нуля покрасить, т.к. старый слой краски будет все равно из под нового объемно выделяться. Либо все отчищать от старой краски, либо вообще весь забор выкидывать к чертям.На сколько ко же приятнее и спокойнее на работе, где из гита на любое место в истории вернулся и продолжил заново...
требуешь еженедельные релизы и tbd возникает сам собой )
Помимо названного еще смущает то, что у 7-ки есть откровенные сложности с производительностью при параллелизации выполнения задач. Ну и нам хотелось иметь нечто типа SaaS решения, и на сколько я знаю, 7-ка тоже так может, но со множеством всяких "но"
https://github.com/vat78/orchestrators
В сторону OpenTelemetry тоже пока только смотрим. Не дошли еще руки.
По сравнению с камундой там много чего не хватает. Например, нет возможности весь процесс посмотреть, когда он еще в работе. Меньше возможностей вручную что-то делать с упавшим/зависшим процессом. Ну и, в принципе, когда речь про бизнесовые процессы, то там часто их аналитики рисуют, а с темпоралом это уже не реально )
Все от задач зависит. Для оркестрации наших бэкендовских задач темпорал вполне хорош. Но вот соседней команде для автоматизации бизнесовых процессов он уже не подходит. Они на 7-ю камунду решили вернутся, в надежде что коммьюнити продолжит багфиксы делать после EoL.
а есть ли хоть какая-то внешняя система со 100% гарантией exactly once? )
Ну тут вопрос упирает в уровень паранойи. База данных, по сути, тоже стороннее решение. У каждой системы есть свои особые кейсы, когда она может нарушать заявленные гарантии. Вчера, например, открыл для себя, что Kafka не дает 100% гарантии порядка записей в рамках ключа партиционирования.
Как обычно, везде свои трейд-офы, главное об этом не забывать и заранее учитывать
Всегда идет выбор между тем - "оверинжинирить" или положить в тех.долг. И тут основной вопрос - что дороже.
Например, про интерфейсы частый посыл - когда появится вторая реализация, тогда и сделаем. В такой трактовке кажется действительно дешевле положить это в тех.долг, т.к. неизвестно, когда это потребуется, и исправление выглядит совсем дешевым. Но интерфейсы это не только про наследование и разные имплементации. Интерфейсы еще позволяют описать API некоего блока кода и защититься от использования внутрянки этого кода снаружи. Вот если в таком случае не выставить заранее интерфейс, то потом, когда у вас появится еще один "потребитель" (а это частая история, в отличии от другой имплементации), никто не вспомнит про выделение интерфейса и система начнет превращаться в лапшу (те самые cohesion and coupling нарушаются). И тогда тех.долг становится очень дорогим (порой проще с нуля все переписать, чем распутать все переплетения в системе).
Аналогично и с другими примерами статьи. Надо оценивать стоимость оверинжиниринга и стоимость тех.долга. Тот же однострочный метод с вызовом другого метода ("middle man"), что дешевле - сделать его сейчас (и иметь лишний переход при дебаге и в стектрейсах), или рефакторить когда потребуется добавить дополнительную логику в него с учетом особенностей использования всеми его потребителями. Каждый раз стоит об этом задуматься: а не делать на автомате то, что написали в книжке, или в статье из интернета.
Чаще всего, многие вещи в книжках как раз написаны для того, чтобы при написании больших сложных систем сделать чуть больше работы, но зато обеспечить себе более дешевое развитие и изменение этой системы. Если у вас вся сложность системы заранее разбита на понятные блоки в виде простых микросервисов, то вы этот "оверинжиниринг" уже проделали заранее и нет смысла его еще и в код тащить (хотя в этом случае, я бы вообще задумался - а зачем вам там java)
С Camunda 8 в 2024-м году возникла существенная "не техническая" проблема - она окончательно стала платной для прода.
Интересно, как вы это решаете в OpenBPM
Все равно потом может начать в тимлидство выносить. Уже сознание немного иначе работает, чем у рядового разработчика, на проблемы чуть иначе смотришь, и люди это помечают и тебя начинают снова в тимлидство подталкивать. Либо у самого может начаться ностальгия. В западных компаниях есть возможность тудя-сюда перемещаться. А вот в российских что-то пока встречал только возможность лишь в одну сторону двигаться
Завязывать доменную модель приложения на схему базы данных - странное решение. Получается, мы нюансы хранения данных тащим в бизнес логику. А без такого подхода Hibernate не будет работать.
Т.е. мне сама идея ORM, где схема данных матчится 1 к 1 в бизнес сущности приложения, кажется нарушением DDD, Clean Architecture и проч.
мой изначальный посыл как раз и был, что рич модель в ООП как раз и заставляет сначала подумать о дизайне. Ведь очевидно, когда в бизнес сущность Курс тащишь сервис для отправки email - это дикость. А вот в анемичной модели в CourseService затащить EmailService - вполне нормальное решение. Хотя по сути, это одно и тоже - нарушение границ контекста и смешивание уровней абстракции
вы опять дизайн системы путаете с имплементацией дизайна )
Прежде чем писать код, сначала было бы не плохо "причесать" бизнес требования и выстроить архитектуру системы. DDD тут в помощь. Когда из-за упавшего почтового сервиса у вас пользователи не смогут курс оплатить - я думаю, не очень хороший бизнес сценарий.
Да, но нет. Анемичная модель никак не может запретить менять состояние сущности из любого места в обход API, предоставленного сервисом. Если с кодом работает больше одного человека, то рано или поздно это произойдет. Плюс в сервисах возникает большой соблазн добавлять зависимости на другие сервисы и ответственность этого сервиса начинает сильно разрастаться (со всеми последствиями нарушения single responsibility).
А если у вас в контроллере происходит маппинг сущности, которую сервис вернул в DTO ответа - это толстый контроллер, или еще нет?
В простых ситуациях я могу и в контроллере оставить связывание разных слоев приложения воедино. В более сложных это логично выносить на новый уровень абстракции (как и в ситуации, когда повялется другая точка входа, типа консольной команды)
Вот как раз подобный код (правда на Java) я и вижу чаще всего в легаси проектах. Его легко писать, но поддерживать и развивать его очень трудно. Автор статьи, которую мы обсуждаем, очень пропагандирует использование конечных автоматов, так вот задача из вашей статьи идеально ложиться на стейт-машину. И это снимает проблему блокировок, упрощает валидацию и т.д. Собственно ваша статья как раз показывает, когда
ООПанемичная модель определила архитектуру вашего решения.