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

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

Ну я ж говорю — DDD не построит за вас нормальный рабочий процесс. Утрируя, если принят стиль "сначала пишем код, а затем узнаём, что он должен был делать", то тут уже ничего не спасёт

Никакие красивые слова не отменяют ТЗ. Как вы ещё собираетесь обосновать заказчику, за что он вам банкет оплачивает?


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

Ок, кривая аналогия: зубную щётку покупают, чтоб у вас была щётка или потому что зубы надо почистить?
Сам по себе, в отрыве от его прикладных функций, продукт не имеет никакой ценности (про фетишистов не будем). Продукт получается, не когда написали N строк, а когда у заказчика вместо двух отделов справляется один человек и приёмку подписывают со словами "спасибо конечно, но больше никогда так не делайте"


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


S>>У вас есть часть, которая практически гарантированно не меняется — модель предметной области.
O>А зачем тут новые 3 слова ддд, чем это не вписывается в практику 90х — каждая сущность класс и в бизнеслогике эти классы взаимодействуют.
Ну блииин... Да не поменялось ничего принципиально ещё со времён мифического человекомесяца. Разведка-обдумывание-реализация-контроль и так до посинения, вопрос только в вкусе фломастеров отдельных нюансах.

Ну, если совсем грубо: В DDD предлагается шлёпать сущности не абы как, а отражая реалии предметной области (см в предыдущем посте пример с сотрудником), вот и всё.