давайте по-простому. на том, что понятно и близко особенно мне.
когда вы пишите торговую инфраструктуру, будь это hft или просто алготрейдинг, хочется сделать универсальную штуку, чтобы можно было менять стратегии, как картриджи, и бэктестить их. и быть уверенным, что все остается на уровне в других местах. я делал это много раз по-разному. за года выработался определенный рефлекс. я решил упростить для себя и вас это дело. буду и дальше развивать.
на вас все еще лежит ответственность за написание стратегии (модели) и самих коннекторов. сами коннекторы можно выносить в отдельные крейты и переиспользовать, а также плодить. хотите, моэкс данные/экшены - имплойте интерфейс и в разных моделях юзайте. модель - это бизнес логика (торговая стратегия в мире трейдинга).
и самое главное, что это все делается мной с максимальным уклоном в производительность и сокращение життера
Да, это отличается от пару потоков + бесконечный цикл + своя очередь. Либа даёт готовую обвязку для жизненного цикла потоков, отмены, бэк-прежура и закрепления потоков за ядрами. Четкий паттерн.
На уровне кода это всё равно обычные системные потоки и in-memory очереди, но с уже решёнными острыми углами: корректное завершение, единый хэндл, метки здоровья, выбор CPU, единые ошибки/таймауты. Поэтому получается надёжнее и масштабируется без боли, а оверхед микроскопический.
Либа для масштабирования. При желании можно event-driven бэкенд придумать. Скоро появятся http/nats сервер вокруг этого.
Главная фича - это готовый интерфейс для написания коннекторов и стримов, которые заслуживают отдельного крейта, но база будет здесь.
Спасибо, сейчас ознакомлюсь. Хотя я прекрасно знаю, что это. Мы тоже так делаем. Только мы в отдельном файле все контракты храним, чтобы следовать правилу единой ответственности. Ну, типа ITicketSystemGateway, INotificationService.
Во многом с вами согласен. Про имейл - пример как аналогия, абстрактный. То, что вы говорите про контроллер, который вызывается в другую функцию, это 3 вариант, описанный мной. Вариант рабочий. Но когда пример более сложный, начинаешь задумываться.
Может ссылаться и ссылается, может, я неправильно вас понимаю?
да, в ваших словах есть логика. Но у такого подхода есть недостаток. Вижу, я не совсем легко и доступно объяснил, поэтому можете почитать про трилемму в ddd
Что касается событий, да, есть такое. Но мы достигаем слабой связности и других преимуществ, которые зачастую перевешивают это. В любом случае, проблема в том, что проблема не решается))
Знаете, можно по-разному. К сожалению или к счастью, теория не настолько хороша, чтобы быть универсальной и полноценной. Как всегда, все зависит от команды и проекта.
ну а доменный сервис - это все же доменный именно сервис, поскольку в нем есть бизнес-логика, которая должна оставаться на уровне домена. Если вы захотите сделать новое приложение (например, приложение для десктопа и веба у вас отличаются по тем же бизнес требованиям), то вы не размазываете эту логику по приложению, а храните все в домене для поддержания консистентности модели
Здравствуйте. В интернете сможете найти различные варианты реализации. Если необходимо, могу ссылки покидать. Как делаем мы в команде:
У нас есть BaseEntity, IAggregateRoot.
В инете в основном в одном из вариантов реализации методы событий лежат в абстракции BaseEntity. Так как мы работаем с паттерном аггрегата, то делаем еще одну абстракцию: BaseAggregateRoot, в которую и помещается маркер. И уже все наши агрегаты наследуем от нее, чтобы сами entity не могли события добавлять.
я понял, о чем вы. но нет
давайте по-простому. на том, что понятно и близко особенно мне.
когда вы пишите торговую инфраструктуру, будь это hft или просто алготрейдинг, хочется сделать универсальную штуку, чтобы можно было менять стратегии, как картриджи, и бэктестить их. и быть уверенным, что все остается на уровне в других местах. я делал это много раз по-разному. за года выработался определенный рефлекс. я решил упростить для себя и вас это дело. буду и дальше развивать.
на вас все еще лежит ответственность за написание стратегии (модели) и самих коннекторов. сами коннекторы можно выносить в отдельные крейты и переиспользовать, а также плодить. хотите, моэкс данные/экшены - имплойте интерфейс и в разных моделях юзайте. модель - это бизнес логика (торговая стратегия в мире трейдинга).
и самое главное, что это все делается мной с максимальным уклоном в производительность и сокращение життера
договорились
Спасибо! Тут столкнулись два разных «латентных».
В инженерном контексте «латентность» -это калька от latency (задержка/время отклика)
Да, это отличается от пару потоков + бесконечный цикл + своя очередь. Либа даёт готовую обвязку для жизненного цикла потоков, отмены, бэк-прежура и закрепления потоков за ядрами. Четкий паттерн.
На уровне кода это всё равно обычные системные потоки и in-memory очереди, но с уже решёнными острыми углами: корректное завершение, единый хэндл, метки здоровья, выбор CPU, единые ошибки/таймауты. Поэтому получается надёжнее и масштабируется без боли, а оверхед микроскопический.
Либа для масштабирования. При желании можно event-driven бэкенд придумать. Скоро появятся http/nats сервер вокруг этого.
Главная фича - это готовый интерфейс для написания коннекторов и стримов, которые заслуживают отдельного крейта, но база будет здесь.
Я понимаю. Это интересно. Своего рода гибридное решение. Кстати, того же мы достигаем с интерфейсами evendhandlers в доменном слое для тех же тестов
Вы правы, различия есть. Почитал. Никогда не слышал об этом паттерне. Ценная информация. Спасибо!
Спасибо, сейчас ознакомлюсь. Хотя я прекрасно знаю, что это. Мы тоже так делаем. Только мы в отдельном файле все контракты храним, чтобы следовать правилу единой ответственности. Ну, типа ITicketSystemGateway, INotificationService.
Во многом с вами согласен. Про имейл - пример как аналогия, абстрактный. То, что вы говорите про контроллер, который вызывается в другую функцию, это 3 вариант, описанный мной. Вариант рабочий. Но когда пример более сложный, начинаешь задумываться.
Может ссылаться и ссылается, может, я неправильно вас понимаю?
да, в ваших словах есть логика. Но у такого подхода есть недостаток. Вижу, я не совсем легко и доступно объяснил, поэтому можете почитать про трилемму в ddd
Что касается событий, да, есть такое. Но мы достигаем слабой связности и других преимуществ, которые зачастую перевешивают это. В любом случае, проблема в том, что проблема не решается))
Отличное решение, по сути, тот же репозиторий, только называется по-другому
Знаете, можно по-разному. К сожалению или к счастью, теория не настолько хороша, чтобы быть универсальной и полноценной. Как всегда, все зависит от команды и проекта.
ну а доменный сервис - это все же доменный именно сервис, поскольку в нем есть бизнес-логика, которая должна оставаться на уровне домена. Если вы захотите сделать новое приложение (например, приложение для десктопа и веба у вас отличаются по тем же бизнес требованиям), то вы не размазываете эту логику по приложению, а храните все в домене для поддержания консистентности модели
Во многом с вами согласен.
Здравствуйте. В интернете сможете найти различные варианты реализации. Если необходимо, могу ссылки покидать. Как делаем мы в команде:
У нас есть BaseEntity, IAggregateRoot.
В инете в основном в одном из вариантов реализации методы событий лежат в абстракции BaseEntity. Так как мы работаем с паттерном аггрегата, то делаем еще одну абстракцию: BaseAggregateRoot, в которую и помещается маркер. И уже все наши агрегаты наследуем от нее, чтобы сами entity не могли события добавлять.