Как работает управление, управляемое поведением (BDD), с дизайном Driven Driven Design (DDD)

Мое понимание BDD заключается в том, что описывается система в истории пользователей, а затем разработчики берут эти истории пользователей и превращают их в приложение с намерением добавить реальную ценность для бизнеса с каждым "спринтом" (период разработки программного обеспечения). Результат (насколько я могу судить) заключается в том, что модель домена возникает из истории пользователей в течение всего процесса разработки. То есть, после первого "спринта" большая часть модели домена не была спроектирована.

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

Это, по-видимому, фундаментальное различие между этими двумя подходами. Как люди справляются с этим?

ОТВЕТЫ

Ответ 1

BDD сделано хорошо, не создает "полную" модель. Там причина, по которой Дэн Норт, парень, который придумал BDD, называет свой блог "охватывающий неопределенность" .

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

Известные вещи просты - например, вход в систему. Это хорошо понято. Нам не нужно разговаривать по сценариям.

Знающие вещи обычно связаны с доменом или с тем, что было сделано раньше. Это отличное место для BDD, поскольку оно помогает передавать знания, включая модель домена, - от бизнеса до разработчиков. Разговор по сценариям - отличный способ лучше понять истории. Это также поможет нам найти сценарии, которые мы пропустили. Крис Маттс, который аналитик, который помог поставить "Given" в "Given, When, Then", называет это "нарушением модели". Он действительно предлагал призы для всех, кто мог придумать сценарий, который не был охвачен в его модели, который он использует для определения и уточнения сценариев.

Там также непознаваемый материал. Это происходит всякий раз, когда мы работаем над чем-то новым или чего-то, чего мы никогда раньше не делали, или чего-то, у кого нет опыта. Вы можете сказать, находитесь ли вы в этом месте, потому что деловые люди начнут реагировать с удивлением, когда вы придумаете сценарии, о которых они не думали. BDD - действительно отличный способ найти эти места, но на данный момент вы, вероятно, захотите перестать пытаться прибить сценарии и просто попробовать что-нибудь и получить обратную связь. Ваша модель домена, ваши истории пользователей и ваши сценарии постепенно появятся (увидеть сложный домен в модели Cynefin).

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

Что касается DDD, когда мы делаем это с BDD, мы склонны фокусироваться на тех частях модели домена, которые имеют отношение к сценариям, над которыми мы работаем, хотя мы могли бы иметь представление о большей модели домена в целом. Если вы используете Feature Injection вместе с BDD, вы уже поговорили бы с большинством возможностей системы, особенно с новыми, так что у вас будет представление о том, какие вещи находятся в домене. Эволюция и все остальные правила все еще применяются. BDD и DDD работают действительно, очень хорошо вместе, с разговорами вокруг сценариев, помогающих выявить язык домена. Они не принципиально разные, но полностью поддерживающие и совместимые.

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

Ответ 2

Я бы включил рассказы пользователей, DDD и BDD, поскольку они очень сильно зависят друг от друга. Я попытался подытожить ссылку здесь: http://christophelecoent.wordpress.com/2013/06/17/how-to-link-user-stories-ddd-and-bdd/

Я надеюсь, что эта картина проста и достаточно богата, чтобы объяснить связь между этими "концепциями"