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

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

O>>Ну допустим понимание терминов заказчика можно преодолеть, особенно если они не все сразу появляются.
S>Снова — не в ту сторону думаете

S>Речь не о понимании терминов. Речь о построении боль-менее рабочей ментальной модели предметной области.
S>Рабочей — не в смысле всемогутора, а в смысле, что она применяется и понимается всеми участниками процесса разработки, от представителя заказчика и до QA.

S>Речь о самих терминах, о списке ключевых сущностей и связях между ними. Не надо начинать с фаулеробреда аля "сотрудник — это сущность с атрибутами ФИО...". Вас интересует что-то вида "сотрудник — это физлицо, принятое на работу в конкретной организации" — увидели, что у нас как бы между прочим появляется как минимум три связанных понятия? И, что самое важное, они никуда не денутся хоть через год, хоть через десять и на это можно смело закладываться при дальнейшем анализе.

Допустим , но в конечном счете даже на этом этапе заказчику этот анализ и разговор на его языке не нужен.
Ему нужен программный продукт, в вот собственно продукт получается когда мы написали N cтрок кода. Как я понимаю ддд говорит не только о том что вникайте в предметную область, разговаривайте больше и понимайте, он говори также как строить код.
Ведь вот эти штуки : Entity, ValueObject, BoundedContext сыпятся именно из статей / книг по ddd.

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