Код в любом случае описывает бизнес-процесс и привязывается к происходящему. Вы не могли бы не описывать бизнес-процесс

— без DDD вы бы могли писать код понятным?
— с усложнением кода и риском ошибок — да
— тогда вам не нужен DDD

вы меня за дурака держите?

Я не сказал что он вам не нужен. Я сказал что он не критичен, а потому, возможно, не оправдан. Всё что я от вас услышал касаемо сложности это цифра 15 сценариев и ничего более. Если вы согласны с тем что способны написать понятный, прозрачный и прибыльный код без применения DDD - для бизнеса это более чем достаточно.

ладно, признаю, что я попал в капкан слово "понятный", тк не обратил на него должного внимания

нет конечно, понятным в моем случае без описания процессов и агрегата было бы не возможно

“в моем случае без описания процессов и агрегата было бы не возможно” - и вот почему я в вас верю больше чем вы в себя? 🙃

И нет, я не пытаюсь выкладывать капканы в этой дискусии

все, сорян, что развел тут спор, я откланяюсь, вы правы, у меня не ДДД, просто что-то, что полностью попадает под его определение и условия, на этом и разойдемся

Смотрите, моя позиция проста. Если вдргу меня позовут и скажут оцените эти 25 проектов по степени трушности (каноничности) DDD - я бы спросил… Например: “А как и где вы храните словарь общего языка предметной области?” Понимаете? Или: “А как и кто у вас фасилитирует сессию event storming-а?”
И вот с ответов на такие вопросы я бы сформировал мнение о том на каком уровне в компании/проекте внедрены подходы DDD. Потому что если я вижу в проекте просто три директории и разделение на контексты и агрегаты - это, возможно, хорошо. Но это всего лишь часть, а не каноничность. Как и говорил ранее - это как Scrum. Он есть у многих, но никто не внедряет его полностью.
Потому у вас DDD, просто не весь.

И зря вы поудаляли сообщения…(

и "другие способы" в отношение DDD в виде SOLID и паттернов — не корреткная отсылка, тк DDD им не противоречит, то есть не попадает в термин "другие"

словари и вот это все — признак сложного проекта
это не говорит о подходе раработки ничего

я признаюсь, у меня этого всего нет, тк проект МИЗЕРНЫЙ вообще, но с гордостью может брать на себя соответствие DDD

Они другие и они не противоречат

Но это говорит о подходе DDD

нет

Предлагаю продолжить завтра, если у вас будет желание и время

другие — есть противоречие
другой = не этот

если DDD не этот (SOLID, паттерны), то он противоречит

если с этим согласитесь, то надо все же будет найти "другие" методологии разработки

“MySQL и другие реляционные базы данных”. Вы придираетесь.

верно, и другие, то есть "не эти", например Postgres

а вот "MySql и другие  индексы в БД" — уже не корректно

я не придираюсь, я навожу вас на мысль, что "другие" — это CRUD и анемичные модели с кучей несемантических сервисов, что просто мусорно по отношению к простому описанию бизнес-процесса

иными словами, я хочу сказать, что круд действительно полезно иногда делать
но там где логика и появляются сценарии, то DDD — простой и легкий способ сократить код и сделать всем легче, да, даже без Event Storming  и словарей, тк ПРЯМО описывает то, что проиходит, то есть является МИНИМАЛЬНЫМ ПРОСТЫМ КОДОМ

к словам не придираюсь, тут просто это принципально по обсуждению

Доброго.
Мне тут кто-то meilisearch рекомендовал.
А как его правильно реиндексировать? Я думал, можно rename индекса сделать. Тогда да. Боевой - стоит. Запасной - заливается. Потом один грохаем, другой переименовываем. А там нельзя.
Получается, downtime все равно неизбежен во время полной индексации?