хзхз)

(я в последнее время становлюсь свидиетелем срачей вида "прививка - чип била гейтса", поэтому ваш спор - бальзам на душу)

доменная модель живет отдельно и она независима от технологий которые живут на уровнях ниже. ничто не мешает сделать мэппер Customer -> ActiveRecordCustomer и обратно

были попытки сделать "правильный DDD" для Django, в итоге получалось много сложного кода, то есть не очень практично всё это было

И это на самом деле удобная штука
Потому что сначала ты начинаешь писать бизнес логику модели в перемешку с Eloquent штуки, и там уже простыня кода

в итоге, наверное, лучшее, что придумали - Django API Domains, там оставили модели как есть из практических соображений

Лара больше на слуху, это правда. Но это НИЧЕГО не значит же. Если судить по хайпу можно подумать что у всех сноуфлейк с гошкой серверлесс и свелте на фронте. Тем временем мир как говнокодил на джаве так и говнокодит

никогда не получится сделать “правильный DDD” для “ваша технология”. Это не проблема джанги, а того как понимаете DDD

моя мысль была вот о чём: для меня DDD это некий правильный идеальный мир с единорогами и чистой архитектурой, которого лично у меня нет и никогда не будет, но на который можно посмотреть и позаимствовать некие подходы (и оставить как идеал, к которому стоит стремиться), так вот если в реальном проекте реального мира есть ORM с Active Record, попытка притащить туда какие-то вещи из идеального мира с DDD приведёт в итоге к получению кучи сложного кода, без которого в итоге окажется лучше, чем с ним... не претендую на правильность понимания DDD если что... ActiveRecord при этом мне в целом нравится (если бы не нравилась, то и с Django стоило бы уходить, весь проект держится на Django ORM), особенно если речь идёт о прототипах проектов (собственно, Django API Domains - это то, что мне нравится и что я поддерживаю как правильный подход для разработки прототипов проектов на Django)

Вот zendesk конечно намудрили

Господа, а посоветуйте для tailwind тему с таблицей, где есть выбор столбцов, сортировка и куча других фич для table-ориентированного  интерфейса

DDD это просто один из подходов как стуктурировать сложные бизнес системы и взаимосвязи между ними. DDD это в первую очередь про bounded context, context map и strategic design,  а не о гексагональной архитуре или о том как реализован repository pattern.

repository pattern отдельно от DDD? ну, тогда я и правда говорил не про DDD, а про него (в моей картине мира эти вещи как-то всегда рядом шли)

Можно жить в мире DDD вообще без Repository Pattern. Суть DDD рассматривать бизнес в разничных контекстах и о том как эти контексты связаны между собой:  https://virtualddd.com/static/a9ec81fddc7912dab0832ddf3344f564/00d43/context-map-cheat-sheet.png

эти части мне близки как раз, я сам активно рекламирую https://github.com/ddd-crew/ddd-starter-modelling-process (тут хорошо описан процесс + Event Modeling ещё иногда к нему)

просто мне всегда почему-то казалось, что правильная полная реализация должна включать в себя репозиторию (но может быть я ошибаюсь и паттерн репозитории не является настолько важным как мне кажется)

а это с ActiveRecord удобным образом сделать не получится (получится гора сложнопонимаемого командой разработчиков кода, который захочется не использовать, а просто удалить)

справедливости ради, Ruby не единым ActiveRecord живет и достаточно популярен еще Sequel - https://github.com/jeremyevans/sequel

80% интернета: https://w3techs.com/technologies/comparison/pl-aspnet,pl-php

намана)