Лично пережил эту хрень, 13 лет назад, остановиться не могу) и мне это даже нравится! Бросил lineage и dota, играл как зависимый, с тех пор ни разу не запускал.

Только у меня была проблема начать, это надо силу воли иметь огромную, а я только поверхностно понимал, что гублю жизнь отсутствием развития.

Мне очень помог метод из НЛП, точного названия не скажу, но смысл в перебросе получения удовольствия с одного занятия на другое. Я занимался тем, что представлял как начну играть в линейку лучником или катку в доте за Гулю рубану, и как только приходил дофамин - сразу садился программировать. Как только отпускало - вновь начинал представлять. Таким образом, через неделю, я уже получал дикий кайф от программирования. Единственная проблема, что быстро заканчиваются вредные привычки, а скучных и полезных дел ещё вагон.

Использовать ide, которая индексирует файлы в проекте и передает аналитические данные неизвестно куда?

Использовать облачные github и gitlab, которые предоставляют индексированный поиск по приватному проекту?

Наверно можно не особо париться по этому поводу, copilot уже видел ваш код)

Copilot / codeium / gigacode такие же инструменты как и ide. Ими просто надо научиться пользоваться. Начать желательно именно с чата, научиться создавать такой промпт, чтобы бот генерировал правильный код. Тогда практически любой помощник будет по комментарию писать полноценные функции.

Из этих трёх я выбрал codeium. Очень хорошо все угадывает, быстро работает, умеет индексировать проект целиком, микро модель запускается прям в ide. Данные передает по защищённым каналам. Бесплатный навсегда. Доступно без vpn.

Gigacode тоже хорош, но не дотягивает пока до codeium

Юзай бесплатный codeium. Ни чуть не хуже, а местами значительно лучше copilot

Для отображения данных лучше не использовать агрегаты совсем. Даже если в текущий момент данных достаточно, то не факт, что в будущем не появятся новые поля.

Очень сильно упрощает работу разделение моделей получения данных и агрегата изменения данных.

Спасибо за статью, на личном опыте знаю как сложно сделать статью полезной и понятной большому числу людей.

В предложенном варианте есть несколько проблем, которые хотелось бы обсудить:

1. Публичные свойства агрегата дают не только возможность изменять, но и читать данные, что дает возможность разработчикам обойти правило чтения данных через соответствующие модели. В идеале не должно быть возможности в сервисном слое получить в память экземпляр агрегата на чтение.

2. Метод репозитория должен представлять транзакционную границу. Если разработчик, работая в сервисном слое, задумывается о транзакциях, значит утекла абстракция и мы уже не можем менять хранилище. Если необходимо транзакционно изменить два агрегата, то либо накосячили при проектировании, либо можно обойтись событийной согласованностью. Менеджер транзакций в ДДД говорит о проблеме.

3. В идеале лучше иметь отдельный репозиторий на каждый агрегат и отдельно для моделей чтения данных, не смешивая команды и запросы. Паттерн CQRS хорошо подходит для подобных вещей.

4. Нет ничего о доменных событиях, что практически является основой для общения агрегатов. Именно на событийной согласованности, в противовес транзакционной, строится независимость агрегатов. Сохранение агрегата всегда должно сопровождаться сохранением события. Паттерн outbox идеально вписываться в подобных случаях.

Мне бы еще хотелось добавить, что важно понимать как определить агрегат, сейчас очень популярно использование event storming. На личном опыте могу сказать, что только после знакомства с ним начал понимать суть ДДД и как должен вести себя агрегат с репозиторием.

Тогда добавьте cratedb. Уделает половину из представленного списка. Ещё, помимо clickhouse, ydb есть у Яндекса.

Event sourcing тоже хорошо подходит для подобных задач, но решение на триггерах тоже имеет смысл в некоторых частных случаях

err := orders.Apply(ctx, orders.FilterByID(orderId), func(order orders.Order) error {
	_ = order.RemoveGoods(goodFilter)
	_ = order.AppliedAbsolutDiscount(0.8)
	_ = order.AddGifts(user)
    // Опустил обработки ошибок
	return nil
})

Я так пишу, очень удобно, orders.Order - интерфейс состояния агрегата, прямого доступа к свойствам нет, менять структуру состояния можно в любой момент и как угодно. Методы кидают ошибки бизнес логики, если не могут выполниться.
Apply вторым аргументом может принимать интерфейс фильтра, который внутри orders может превращаться во что угодно. Все это живет с gorm очень хорошо. Количество фильтров строго ограничено, они все исключительно бизнесовые кроме FilterByID.

Репозитория как такового нет. orders по факту инкапсулирует состояние и его хранение, принимает в себя коннект к бд, в моем случае gorm.

Для отображения наружу такой "репозиторий" ничего не возвращает, он только предоставляет интерфейс для изменения состояния с глобальной блокировкой.

Методы AppliedAbsolutDiscount создают события внутри состояния, которые в конечном итоге сохраняются в бд и обрабатываются аутбоксом.

Чисто мое мнение, если нужно просто получить и отобразить, то это, вероятнее всего, фильтр в репозиторий и полное отсутствие агрегата. Там должна фабрика из данных базы переложить все в отдельную структуру. Если поиск будет усложняться, то вы скорее всего перейдете на соответствующее хранилище, старые структуры уже окажутся не актуальны, а значит на них не желательно завязываться изначально. Мало того, в микросервисной архитектуре вы с огромной вероятностью начнете использовать паттерн CQRS, а значит код продвинутого поиска уйдет в отдельный сервис и вся соответствующая бизнес-логика отображения окажется уже там. Все ситуативно, два биллинга в разных бизнесах всегда будут написаны по разному)

Агрегаты, опять же, по моему личному мнению, очень хороши при создании и обновлении данных. Там бизнес логика уже и нужна. Простой пример: чтобы отобразить статус клиента - просто достань статус и покажи, но вот если клиент его меняет - кинь пару ивентов в соседние сервисы, обнови дату последнего изменения статуса, а если статус стал online в момент ожидания ответа, то оповести об этом менеджера опять через ивенты.

Поэтому получение списка 10 клиентов в городе N с наибольшим количеством отменённых заказов в этом городе я бы делал через поисковой движок без применения агрегатов.