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

Определённости словам в языке мало что добавит. Это так даже в математике (например, якобианом называют то определитель, то саму матрицу -- https://ru.wikipedia.org/wiki/%D0%AF%D0%BA%D0%BE%D0%B1%D0%B8%D0%B0%D0%BD). Agile IMHO (как и многие другие инженерии) потихоньку бредёт к принятию системного подхода. При этом, конечно, и сам системный подход тоже потихоньку меняется, развивается. В учебничке, я думаю, вы уже прочли, что различение модульного и компонентного разбиений системы уже есть (хотя и в чуть разной терминологии) в большинстве инженерных подходов и зафиксировано в самой разной литературе. Agile начинал с совместного инженерного и менеджерского рассмотрения, потом ушёл на чисто менеджерские (http://ailev.livejournal.com/1183548.html). Но от инженерных-то задач не уйдёшь! Конечно, и product backlog и user story map это какие-то гибридные описания: в явном виде в agile на этом уровне архитектурной работы и планирования работ не различают модули и компоненты и не обсуждают их соответствие друг другу. Тем не менее, как я написал в посте, есть два разных разговора: один из них про "из чего будет состоять наш продукт, как его мы будем делать" -- и так формируется product backlog. При этом, конечно, по определению меньше внимания уделяется вопросу "из чего будет состоять наш продукт, чтобы он работал" -- и дальше там нужно обсуждать интерфейсы и модули. И вот для этого и используется прежде всего user story map и сдвижка в DDD. Это функциональные описания, функциональные требования. И мне кажется, что если это недоговаривать, то product backlog и user story map будут одними и теми же гибридными карточками, только немного по-разному перетасованными. Но цель-то у авторов user story map и DDD другая, обсудить они хотели бы другие вопросы! Поэтому я и сожалею, что они прямо не говорят о двух разных видах описаний. Конечно, эти два вида описаний только самое начало. Ещё есть размещение, ещё есть различение в описании вещей (objects) и связанных с ними изменений (activities), есть описание сигналов, но это всё потом. Надо начать хотя бы с различения FunctionalPhysicalObject и Inanimate PhysicalObject (если в терминах ISO 15926 -- это разделение ведь практически везде в инженерии есть). Дальше можно было бы возвращаться к обсуждению backlog и говорить, что там объекты предпочтительно другого типа, нежели в user story map. И в user story map предпочтительно другого типа. Но соотношение между ними может быть 1:1, и названия похожи, так что разницу мало кто заметит. И user story map может хитрым образом переходить на какую-нибудь kanban доску, где тот же product backlog уже. Гибридность использования user story должна быть обсуждена явно, это нормальное архитектурное обсуждение. Когда речь идёт о сложных инженерных задачах, разделение функционального и физического обсуждения становится общим местом. И требование задержки обсуждения на функциональном перед тем как начинать обсуждать физическое тоже становится общим местом. User story map всё это делает, но больше "интуитивно" и без особого объяснения, почему ими предлагаемое решение вдруг хорошо работает. Вот вы требуете какой-то определённости и формализма, но поглядите, насколько отсутствует формализм в описаниях user story map и как тщательно явно оговаривается, что никакого там формализма нет! Ибо почему-то осмысление и точная терминология кажутся лидерам agile чем-то стесняющим творчество. Ну, увы.