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

S>>фичи — это вообще не про то, как должен использоваться код. Это о том, что если для реализации фичи надо будет все сломать и построить заново, то так тому и быть. Разумеется, это вульгарное объяснение, т.к. разработка базовой модели должна предвосхищать работу над фичами.

S>так получается ничего не мешает построить домен и фичи над доменом?
Построение базовой модели (на бумаге) — первичный этап FDD. Наверняка туда войдет и домен и данные (или их схема).

S>только непонятно как это выглядит архитектурно.
S>к примеру если в DDD был контролер из которого вызывался репозиторий, то тут просто CreateUserFeature которая внутри состоит из кучи подключаемых по возможности фич?
у DDD нет и не может быть исключительного права владения над контроллером и репозиторием. Т.е. они могут быть использованы при любом стиле разработки. Точно так же, как и тесты можно писать не только лишь в ТДД.

S>Если не затруднит просто пример кода могли бы накидать в вариента FDD и что-то другое
Конечно затруднит. Мы ведь не о микроуровне (коде) говорим, а о разнице процессов разработки.

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

Как это отразить в примере кода на форуме — я не знаю.