Akka.Net — порт одноимённого фреймворка Akka из Scala-мира. Если я правильно понимаю портированием и коммерческой поддержкой занимается Petabridge. Поэтому функционал есть, а документация местами отсутствует. Но отсутствующую документацию по Akka.Net всегда можно найти в документации для Scala http://akka.io/docs/
Я понимаю что это может быть оверкил, но я бы использовал Akka.Net.
Кинул актору задачу и не переживаешь что он завалится. CircuitBreaker, BackoffStrategy, Supervising из коробки.
Ну и до кучи персистентность, ремоутинг, кластеринг, и тут Остапа понесло…
Заметил что все кодеры из этого цикла статей, говорят что работают >10ч в сутки.
Я вот работаю 6..8ч (+0..2ч на отвлеченные вещи типа обеда, чтение хабра и прочую прокрастинацию) и думаю что это много, т.к. на свои интересы не остаётся времени, я уж про семью вообще молчу.
А если вспомнить другие обязательства типа в магазин сходить, дома прибраться, поспать, так вообще непонятно как можно по 15ч в сутки пахать.
Декораторы и AOP помогают когда можно полностью запретить или полностью разрешить вызов command/query.
А для запросов по площади типа GetAllProjects() от конкретного юзера надо городить в самом теле запроса логику фильтрации.
В read-model у меня была тонна .Where(UserBelongsToProject) или что-то вроде .Where(EntityNotDeleted) и если я в каком-то запросе пропустил эти фильтры — это потенциальная брешь в безопасности данных.
А если взять какой-то сложный запрос на финансовый отчёт по всем доступным проектам, тут вообще кошмар, т.к. приходится джойнить таблицы и не забывать что для каждой такой таблицы надо тоже применять фильтры.
Получается что мне нужен кто-то на стороне Query, кто решает вопрос доступа к данным, а значит там надо городить отдельную доменную модель, что убивает смысл CQRS.
Один из вариантов: выносить такую логику в АОП, например так. Погуглите Cross-cutting concern. Вот здесь кое-что есть по-русски на эту тему.
Я так и сделал. все что требовало доступа уровня проекта имело маркерный интерфейс IProjectRequest, на который был настроен декоратор, отказывающий пользователю, если это не его проект. Но приходилось это делать и на командах, и на запросах.
Таким образом у меня бизнес логика «протекала» из агрегатов и размазывалась по декораторам. А сам агрегат уже не был самодостаточной сущностью и мог правильно существовать только с внешними декораторами.
Та же проблема и с выделением логики во внешний слой. Логика утекает вообще не пойми куда, а агрегат Проект должен надеяться что вопрос доступа к конкретному проекту был решён за него.
Делал проект с DDD+CQRS (без ES). Была одна непонятка, объяснение которой я не нашёл.
Вот допустим у нас есть проекты и их менеджеры. Есть требование что обращаться по-любому поводу к «чужому» проекту нельзя, даже имя узнать.
Агрегат Проект решал эти вопросы доступа сам, зная кто его менеджер и вся эта логика (она была сложнее и касалась не только проектов) была на стороне Command, в агрегатах.
На стороне Query всю эту логику приходилось дублировать чтобы люди запросами типа GetProjectBudgets(id) не узнали лишнего.
Думал над вынесением логики доступа к ресурсам в отдельный слой, ещё над разделением потоково на Command и Query. Не успел, сменил свой рабочий проект.
Что бы вы посоветовали сделать в этом случае в рамках CQRS и DDD?
Кинул актору задачу и не переживаешь что он завалится. CircuitBreaker, BackoffStrategy, Supervising из коробки.
Ну и до кучи персистентность, ремоутинг, кластеринг, и тут Остапа понесло…
То чувство, когда единственное русское слово в переводе заголовка — вопросительное «как».
Я вот работаю 6..8ч (+0..2ч на отвлеченные вещи типа обеда, чтение хабра и прочую прокрастинацию) и думаю что это много, т.к. на свои интересы не остаётся времени, я уж про семью вообще молчу.
А если вспомнить другие обязательства типа в магазин сходить, дома прибраться, поспать, так вообще непонятно как можно по 15ч в сутки пахать.
Особенно дико смотреть на в языке с прекрасными дженериками.
Декораторы и AOP помогают когда можно полностью запретить или полностью разрешить вызов command/query.
А для запросов по площади типа GetAllProjects() от конкретного юзера надо городить в самом теле запроса логику фильтрации.
В read-model у меня была тонна .Where(UserBelongsToProject) или что-то вроде .Where(EntityNotDeleted) и если я в каком-то запросе пропустил эти фильтры — это потенциальная брешь в безопасности данных.
А если взять какой-то сложный запрос на финансовый отчёт по всем доступным проектам, тут вообще кошмар, т.к. приходится джойнить таблицы и не забывать что для каждой такой таблицы надо тоже применять фильтры.
Получается что мне нужен кто-то на стороне Query, кто решает вопрос доступа к данным, а значит там надо городить отдельную доменную модель, что убивает смысл CQRS.
Я так и сделал. все что требовало доступа уровня проекта имело маркерный интерфейс IProjectRequest, на который был настроен декоратор, отказывающий пользователю, если это не его проект. Но приходилось это делать и на командах, и на запросах.
Таким образом у меня бизнес логика «протекала» из агрегатов и размазывалась по декораторам. А сам агрегат уже не был самодостаточной сущностью и мог правильно существовать только с внешними декораторами.
Та же проблема и с выделением логики во внешний слой. Логика утекает вообще не пойми куда, а агрегат Проект должен надеяться что вопрос доступа к конкретному проекту был решён за него.
Вот допустим у нас есть проекты и их менеджеры. Есть требование что обращаться по-любому поводу к «чужому» проекту нельзя, даже имя узнать.
Агрегат Проект решал эти вопросы доступа сам, зная кто его менеджер и вся эта логика (она была сложнее и касалась не только проектов) была на стороне Command, в агрегатах.
На стороне Query всю эту логику приходилось дублировать чтобы люди запросами типа GetProjectBudgets(id) не узнали лишнего.
Думал над вынесением логики доступа к ресурсам в отдельный слой, ещё над разделением потоково на Command и Query. Не успел, сменил свой рабочий проект.
Что бы вы посоветовали сделать в этом случае в рамках CQRS и DDD?