Без заголовка

Вы неправильно определяете цель user stories и DDD. Этим подходом решается проблема вытащить требования и описания в максимально возможном объёме на естественном языке и поддерживать их (что часто является серьёзной проблемой), а не использовать эти понятия для конструирования системы. Поэтому не должно быть соответствия 1-к-1 между user stories и полученной системой. Любая дополнительная формализация тут будет вредить, потому что формализация так или иначе завязывается на реализацию или какие-то абстрактные понятия и потом мешает эти понятия сменить. Ведь если использовать эти понятия -- то придётся в электронном радио вводить "ручку настройки частоты радио" только потому что она была в обычном радио. В этом нет смысла. Но в том, чтобы детально понимать, какие проблемы хочет решить заказчик и как он их решает сейчас, и не заставлять его говорить в терминах реализации, смысл есть. В DDD цитируется Patton: "Story mapping keeps us focused on users and their experience, and the result is a better conversation". (опущу часть про продукт). Понимаете? Практика заставляет поддерживать два разных языка. Один внутренний для реализации системы, один для более глубокого понимания заказчика. Языки разные, т.к. цели у них разные. Более того, в большой профессиональной команде, где я работал давным давно, были отдельно "business analyst" и "system analyst" и имели они дело каждый со своим языком. Я считаю это хорошей практикой.