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

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

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

мне пока не повезло увидеть ТЗ такое чтоб вот сделал как в нем написано и все были довольны.
Да и какое ТЗ может быть в agile ? Только очень краткое.

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


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

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