Здравствуйте, okon, Вы писали:

O>Допустим , но в конечном счете даже на этом этапе заказчику этот анализ и разговор на его языке не нужен.
В смысле?
Заказчик уже отвалил бабки, не подписав ТЗ? Или ТЗ какой-то другой магией составляется, без тотального выноса мозга заказчику?
Ну а если есть ТЗ — то собственно в чём вопрос-то?
Вы уже собрали всё, что вам нужно, вопрос только в том, как структурировать.


O>Ему нужен программный продукт, в вот собственно продукт получается когда мы написали N cтрок кода.
Нафига заказчику код? Бизнес всегда покупает не продукт, а решение своих проблем. Собственно про это ТЗ и пишется.


O>Ведь вот эти штуки : Entity, ValueObject, BoundedContext сыпятся именно из статей / книг по ddd.
Вот эту часть сразу выкинуть. Книга писалась в 2003 году емнип. В то время Эванс дружил с яваводами и регулярно выступал на фаулероведческих конференциях. Сами прикинете, насколько оно сейчас актуально?


O>Вот как поговорить с заказчиком в рамках работы по ддд мы уже обсудили, хотелось бы понимания а что собственно дальше как это превращается в код, который я так понимаю должен на верхнем уровне быть написан на языке заказчика и легко отражаться на требования.
Так же, как и всегда.
У вас есть часть, которая практически гарантированно не меняется — модель предметной области.
У вас есть структурированные сторилайны. Чего ещё может понадобиться?

Как по мне, так это идеальнейшие условия для.