1) Агрегат должен иметь связанный обьект, но его нет - обрабатываем в useCase (специфичный агрегат)
2) Агрегат имеет связанный обьект - валидируем.
3) В валидаторе - если связанный обьект есть - валидируем.
Все, не надо городить 100 классов агрегатов (100 классов агрегатов - 100 проверок инвариантности). (да, я видел такое, и UseCase-ы в стиле UpdateFieldA(id,FieldA)) Обьясняют необходимостью инвариантности (BestPractice) - надо говорить что нужна только обеспечить валидность данных в хранилище.
Но это с позиции CRM, где гриды и карточки обьектов первичны.
Огромный плюс - 90% кода можно генерировать.
Богатая доменная модель:
Если с UpdateFieldA надо постоянно еще что-то делать - тут богатая модель, чтобы логику при UpdateFieldA не переписывать.
Таким образом вы лишили себя всех преимущств ООП: высокого cohesion, инкапсуляции модели, полиморфизма для разруливания дублирования и абстракции логики. Помимо этого вы перемешали логику уровня приложения с логикой предметной области, и теперь каждый раз надо отделять виски от колы, чтобы что-то понять.
Богатая модель - антипаттерн SOLID.
Попробуйте как-нибудь сделать обьект с 7 различными проверками в зависимости от статуса, например.
А теперь добавим функции сохранения, расчета...
В том же EF инжектить сервисы в обьекты - проблематично.
Вкраце - уже 3 подобных процессора выпустили в кремнии (один в один, переферия другая конечно). Еще в 2000-х.
А в общем - функциональные блоки и связи между ними.
Есть даже OpenSource реализация архитектуры.
В те времена с эвристиками и компиляторами были проблемы (нет нейросетей и эвристик, дай бог 500 MOPS а не 100 TOPS при компилировании нельзя проверить нормальное количество вариантов).
Теперь это преподают как прорыв (но, увы, уже плохо с компилятором).
Я советую ElasticSearch потому что там есть шардинг - поднял на нескольких серверах и хоть 20 Гб\сек ошибок пиши.
Это - идеальный случай для 1 системы (пусть даже с сайтом/WPF и еще командами по шине).
Для локального логирования простых приложений - обычно все в таблицу\файл (или что там у логгера есть).
Проблема в том, что поиск что по БД, что в ElasticSearch скорее всего по скорости одинаковый. Последний разворачивается просто и поддерживает горизонтальное масштабирование.
авторизация\аутентификация - есть в ElasticSearch.
А вот специфических проверок и интерфейсов для логирования - нет.
Большинство так называемых логгеров сами кладут все в БД.
Поиск обычно осуществляется ElasticSearch и подобными.
Хранение логов - ну сделать джоб - удалять Warning-и и Info раз в месяц\неделю.
(А Exception-ы мониторит DevOps, и заводит тикеты)
Сейчас HDD дешевые, можно логи вообще не чистить.
Хотя я видел команды, которые зачем-то заводят отдельную таблицу логов чуть ли не на каждый модуль(со своими таблицами), чтобы смотреть ошибки. (А не просто используют ChangeTracking для записи изменений обьектов в журнал, и отдельный журнал для событий).
Бери все сервисы прямо из контейнера\откуда угодно,
Не нужно создавать никаких оберток для классов.
Единственное, что можно улучшить - сделать свой Weaver для оборачивания всех public методов по атрибуту уже на классе. (для тех кто любит писать код на C# как есть - Класс с логированием, Интерфейс с регистрацией реализаций в контейнере вот так, и т.д)
О, я как раз скачал свой бесплатный ИИ o3 от Nvidia.
(Который с Thinking)
Ай да OpenAI, какие молодцы!
Сказали OpenSource - OpenSource.
А я сомневался
А я уже думал что 200 млрд $ инвестиций в фирму "Занимающуюся разработкой T-9 вместе с учеными из DeepMind, которые слабо разбираются в нейросетях" - это бред, и все идиоты :)
Более сложные лекарства разрабатывались с еще большими букетами побочек (отказ органа(ов) - часто).
От отсутствия антибиотиков прямо умирают (и лишаются конечностей) Много Людей - поэтому туда и направляли миллиарды, и это "относительно безопасные" лекарства :).
Скорее ответ:
Агрегатом из доменных сущностей.
Обычно доменная сущность и связанные обьекты.
Если обойтись без нарушения SOLID:
AutoMapper поддерживает вложенные обьекты,
FluentValidatior поддерживает вложенные обьекты,
EF поддерживает вложенные обьекты.
Возможно несколько ситуаций:
1) Агрегат должен иметь связанный обьект, но его нет - обрабатываем в useCase (специфичный агрегат)
2) Агрегат имеет связанный обьект - валидируем.
3) В валидаторе - если связанный обьект есть - валидируем.
Все, не надо городить 100 классов агрегатов (100 классов агрегатов - 100 проверок инвариантности). (да, я видел такое, и UseCase-ы в стиле UpdateFieldA(id,FieldA)) Обьясняют необходимостью инвариантности (BestPractice) - надо говорить что нужна только обеспечить валидность данных в хранилище.
Но это с позиции CRM, где гриды и карточки обьектов первичны.
Огромный плюс - 90% кода можно генерировать.
Богатая доменная модель:
Если с UpdateFieldA надо постоянно еще что-то делать - тут богатая модель, чтобы логику при UpdateFieldA не переписывать.
Богатая модель - антипаттерн SOLID.
Попробуйте как-нибудь сделать обьект с 7 различными проверками в зависимости от статуса, например.
А теперь добавим функции сохранения, расчета...
В том же EF инжектить сервисы в обьекты - проблематично.
@onets
MediatR-style, для каждого useCase делаем команду и ответ.
Команды уже с доменной сущностью (это уже Application).
Запросы и ответы - и есть отвязка Application от Infrastructure.
Можно сразу переиспользовать все UseCase-ы, и вызывать их откуда угодно.
Маппинг WebDTO-DomainEntity в Infrastructure.
Вкраце - уже 3 подобных процессора выпустили в кремнии (один в один, переферия другая конечно). Еще в 2000-х.
А в общем - функциональные блоки и связи между ними.
Есть даже OpenSource реализация архитектуры.
В те времена с эвристиками и компиляторами были проблемы (нет нейросетей и эвристик, дай бог 500 MOPS а не 100 TOPS при компилировании нельзя проверить нормальное количество вариантов).
Теперь это преподают как прорыв (но, увы, уже плохо с компилятором).
Википедию читали?
Вы не можете запатентовать такое.
Это https://en.wikipedia.org/wiki/Transport_triggered_architecture
Это тот же RISC, только графы испольнения посложнее и побольше.
И вместо миллиарда команд - простая конфигурация исполнительного блока через маленькие команды.
Ну и таких разработок любой, знакомый с абстракцией индукцией и дедукцией выдает по 100 штук.
Карнеги-меллон - не MiT и не KAIST.
И публикаций о подобных процессорах - очень много.
https://github.com/ValeriyAndreevichPushkarev/STA_ring_buffer
Найди 3 отлиция в прорыв процессор великий гений Microsoft империя!
Технология!
Кэш из ячейка фабрика вынесен!
НЕ DPA!
Не СИМИДИ НЕ СИМИДИ!
А представляют процессор как-то вот так:
https://coub.com/view/3eui7i
Компилятор - не очень сложно.
Топологическая сортировка потоков данных (от команды к команде).
И Linear/Integer programming. С эвристиками и без.
Циклы - то же самое, пишем
(Код до цикла)
(Итерация 1)
(Итерация 2)
...
И запускаем топологическую сортировку.
Есть кучи публикаций
Потому что это GroupBy с вызовом агрегирующей функции.
И EntityFramework транслирует все В
Или в EF:
Естественно, можно все переписать, но надо работать с выражениями.
Как я понял - в статье про то, что нужен именно синтаксис как в DAX.
Я советую ElasticSearch потому что там есть шардинг - поднял на нескольких серверах и хоть 20 Гб\сек ошибок пиши.
Это - идеальный случай для 1 системы (пусть даже с сайтом/WPF и еще командами по шине).
Для локального логирования простых приложений - обычно все в таблицу\файл (или что там у логгера есть).
Проблема в том, что поиск что по БД, что в ElasticSearch скорее всего по скорости одинаковый. Последний разворачивается просто и поддерживает горизонтальное масштабирование.
авторизация\аутентификация - есть в ElasticSearch.
А вот специфических проверок и интерфейсов для логирования - нет.
Тут клиент-серверное приложение, как у вас.
А БД избавляет от необходимости 400 Tb SSD?
Вы же сами показали - у Вас один текст, и события - раз в два часа.
Текст в таблице и текст в JSON - разница процентов 10.
Все, что вы описали - крайне избыточно.
Большинство так называемых логгеров сами кладут все в БД.
Поиск обычно осуществляется ElasticSearch и подобными.
Хранение логов - ну сделать джоб - удалять Warning-и и Info раз в месяц\неделю.
(А Exception-ы мониторит DevOps, и заводит тикеты)
Сейчас HDD дешевые, можно логи вообще не чистить.
Хотя я видел команды, которые зачем-то заводят отдельную таблицу логов чуть ли не на каждый модуль(со своими таблицами), чтобы смотреть ошибки. (А не просто используют ChangeTracking для записи изменений обьектов в журнал, и отдельный журнал для событий).
Есть метод проще
https://github.com/vescon/MethodBoundaryAspect.Fody
Делаешь атрибут Log или WithLogging
В OnException вызываешь логирование.
В чем плюс Fody -
Навешиваешь атрибут Log на методы,
Бери все сервисы прямо из контейнера\откуда угодно,
Не нужно создавать никаких оберток для классов.
Единственное, что можно улучшить - сделать свой Weaver для оборачивания всех public методов по атрибуту уже на классе. (для тех кто любит писать код на C# как есть - Класс с логированием, Интерфейс с регистрацией реализаций в контейнере вот так, и т.д)
Таблетки принимаете?
И Корпорации, и Божества,
и Жертвование детей.
Даже Общественное благо и
Суверенный ИИ.
Не знаю как Вы, а я опять скачал о3(о4) из интернета.
Нет у OpenAI технологий, и не будет. Там T9 пытаются доделать.
Все видно на испытательном\собесе.
Вы видели, чтобы кого-то прямо увольняли?
По ТК уволить очень проблематично.
Т.е. половину зп ментору, половину - аутсорсеру?
Кто будет создавать видимость работы, за половину половины пособия по безработице в том же ЕС?
О, я как раз скачал свой бесплатный ИИ o3 от Nvidia.
(Который с Thinking)
Ай да OpenAI, какие молодцы!
Сказали OpenSource - OpenSource.
А я сомневался
А я уже думал что 200 млрд $ инвестиций в фирму "Занимающуюся разработкой T-9 вместе с учеными из DeepMind, которые слабо разбираются в нейросетях" - это бред, и все идиоты :)
Какая-то альтернативная реальность (которая вряд-ли существует).
Везде есть испытательный срок.
Увы, за 3 месяца возможно понять Ваш уровень )
(del)
Да что же такое?
Вы что, забыли про антибиотики и спиртное? )
Более сложные лекарства разрабатывались с еще большими букетами побочек (отказ органа(ов) - часто).
От отсутствия антибиотиков прямо умирают (и лишаются конечностей) Много Людей - поэтому туда и направляли миллиарды, и это "относительно безопасные" лекарства :).
Мда, печаль только в том, что 99% лекарств, разработанных до AlphaFold(3)/Nvidia Microbes можно на помойку выкинуть :)
Учитывая, что деньги на "сверхложный R&D великими гениями" надо еще и отбивать: выпускали (и выпускают) хз что.
Все еще проще, с 200 млрд $ инвестиций 100 идут на публикации на хабре\reddit,
"Как Илон разогнал T-9!"
Уже пора отдельный тег вводить (чтобы банить).
Невероятно, но
простой вывод вроде "Ну и ладно, бесплатный DeepSeek или любой другой Perplexity тоже неплохо" в голову не пришел.