Тут уже что-то из чистого кода, а-ля давайте переменным и функциям говорящие названия

Так и сказать "назови по-человечески!"

Между говорящим названием переменной и кодом отражающим решение задачи на языке предметной области может лежать пропасть

Мне кажется, если логика умещается в один скрипт, то и пропасти быть не может

ну это в целом про нейминг. Где там картинка с «мир глазами ООП программиста»?

Грамотный нейминг, использующий те же термины которыми мы обсуждаем требования, способен существенно снизить когнетивную нагрузку на код. только за счет нейминга проще идти в сторону разделения ответственности. Без понимания нейминга и терминов предтметной области сложно делать декомпоцизию используя information hiding. Я бы не стал говорить что это про DDD (оно хоть и базируется на этих вещах но чуть более высокоуровневая штука, не совсем про код но затрагивает вопросы стоимости перевода требований в оный)

Где про это максимально подробно прочитать?

грубо говоря - если мы с человеком обсуждаем как должно работать в терминах «продукт скидки ежемесячные акции» и т.д. а в коде у нас foo,bar, a, b то такой код уже через пару недель никто не поймет и могут важные требования упустить (врядли такие люди пишут тесты лучше).

Проблема эта называется «стоимость перевода». Вот все эти BDD чуваки оч много по такому загоняются

я б гуглил чет типа requirements code translation cost

Вопрос-то насущный... Вот вчера Акула скидывал проект свой... Ну вот нифига не понятно же)) решение задачи явно не языке предметной области

А сказать ему нечего даже) кроме "а что так сложно, проще нельзя")

Спасибо! Вот вроде именно то, что я ищу.. попробую в эту строку погуглить

лучше в контексте BDD, там про это больше говорят

еще вещь почему это важно - потому что в современных задачах уже не выходит делать так что бизнес аналитик или там еще кто тебе описывает задачку а ты тупо делаешь. Вся эта тема с DDD все больше смысла имеет просто потому что для обсуждения че дальше пилить нужны все экспертизы (то есть не только бизнес но и разработчики, ux челы, вот все вот эти ребята). И им надо говорить на одном языке что бы понимать друг друга. А дальше уже просто логично что в коде ты тоже этот язык будешь использовать.

В целом обычно прям про код никто не говорит (это аля как само собой разумеющееся). Больше про взаимодействие бизнеса и девов. Про это и всякие Джефы Паттоны пишут, и Годжко Адзик и Альбертно Бартолини и куча кого еще (тот же Дэн Норс)

Мож "выразительность"? В чистом коде про всякое такое. Я бывало на ревью кидал ссылки на главы этой книги. Ну а шо )))

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

выразительность, самодокументируемость...

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

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

Наверное стоит действительно с self documenting code начать