Можно ли использовать DDD и BDD вместе? - PullRequest
16 голосов
/ 22 августа 2011

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

Здесь идет бизнес-ориентированный BDD с внешней разработкой. У нас нет предварительного дизайна домена (выбор сущностей, объектов стоимости, агрегатов). Мы берем пользовательскую историю, пишем несколько сценариев и реализуем их один за другим. Мы начинаем разработку с самой изменчивой части приложения - с презентации. Я ненавижу писать хрупкие приемочные тесты. А ты?

Итак, если у кого-то есть успешные истории о применении DDD в стиле BDD, поделитесь со мной некоторыми:)

  1. Вы пишете эти хрупкие тесты для презентации?
  2. Есть ли у вас какой-то дизайн перед созданием части домена для пользовательской истории, которая будет реализована? Или вы реорганизуете паттерны DDD после реализации истории?

Любая помощь будет оценена. Спасибо!

Ответы [ 5 ]

20 голосов
/ 22 августа 2011

Я предлагаю Дэну Норту и себе (прошу прощения, кролик в свете фар, это было мое первое видео), когда он давал интервью одному из коллег Эрика Эванса по BDD и DDD.

Также вы можете получить предварительный просмотр фрагмента черновика первой главы из книги BDD, которую я пишу (надеюсь, с Дэном тоже):

Как еще один эффект, обсуждение сценариев без каких-либо технических слов на деловом языке позволило разработчикам подобрать этот язык. Затем они перенесли этот язык в свою кодовую базу, реализовав классы, названные в честь элементов бизнес-области, методы, названные в честь возможностей этих элементов, а также свойства и переменные, названные в честь их реальных свойств и подэлементов.

Такое использование бизнес-терминологии в коде упоминается как вездесущий язык в книге Эрика Эванса "Доменно-управляемый дизайн". Эрик предполагает, что, когда разработчики начинают кодировать на языке, который соответствует терминологии заинтересованных сторон, разговоры становятся текучими, и разработчикам (или аналитикам в качестве доверенного лица) не нужно переводить технические детали в концепции предметной области. Код становится более читабельным и понятным для новичков. Значение каждого объекта в системе становится более очевидным, а также путь, по которому он возвращает свое значение пользователю, чтобы пользователь мог предоставить ценность для бизнеса.

JBehave представил что-то новое. Мало того, что разработчики использовали язык бизнес-доменов; теперь они использовали язык, который понимал бизнес, чтобы описать терминологию программного обеспечения. Вместо таких слов, как test , приемочный тест , act , range , assert , красная полоса и зеленая полоса , разработчики говорили о примерах , сценариях , контекстах , событиях , исходы и поведение .

JBehave и BDD представили вездесущий язык для самой разработки программного обеспечения.

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

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

7 голосов
/ 22 августа 2011

Позвольте мне добавить прекурсор к моему ответу, что я никоим образом не BDD, TDD или первый эксперт тестирования.Отступление ...

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

Будучи корпоративным архитектором, мои мысли № 1 в области разработки проектов всегда повторяются.Это всегда гораздо более достижимо, когда базовая архитектура будет согласована между проектами, и, что еще важнее, в одном и том же проекте.

Теперь, чтобы ответить непосредственно на ваш вопрос, в моей книге DDD всегда будет на первом месте.По моему мнению, без DDD вы в основном теряете сознание, когда речь заходит о ключевых архитектурных решениях, которые потом могут стать чрезвычайно болезненными.На мой взгляд, DDD является гораздо более высокоуровневой концепцией, которая выражается в блок-схемах высокого уровня.Со многими историями BDD, которые будут включать взаимодействие на уровне DDD между системами.

Что касается вопроса о том, буду ли я писать истории для взаимодействия с пользовательским интерфейсом, то в них определенно есть ценность.Тем не менее, они могут легко быть пропущены вместо времени, необходимого для других начинаний, так как ограничения проекта, как правило, возникают раньше, чем ожидалось.Кодовые тесты пользовательского интерфейса, которые вы пишете, не должны быть хрупкими.Однако, если они хрупкие, они почти бесполезны с самого начала.Если вы будете следовать четкому соглашению об именовании элементов HTML, наряду с написанием семантического HTML, вы можете создавать очень надежные модульные тесты пользовательского интерфейса.Это гораздо легче выразить в MVC, чем в веб-формах (в ASP.NET java, вероятно, имеет какую-то аналогичную параллель).

RE: вы предлагаете создать чистую область домена дореализации историй?

Я бы даже вообще пошёл немного дальше с определением концепций класса Model и интерфейсов сервисов.В тот момент, когда начинается реализация интерфейсов, я начинаю работать над историями.Это также приведет к изменениям моделей или интерфейсов по мере их возникновения.Чтобы оставить все интерфейсы сервисов и модели, которые будут разрабатываться по мере их развития из историй, я чувствую, было бы слишком много туннельного видения.То, что вы начнете создавать модели и / или интерфейсы, которые решают конкретную историю, но не имеют смысла для более широкой картины.

Итак, чтобы действительно подвести итог вашему вопросу о среднем, а не о внешнем.Я чувствую, что они очень способны опираться друг на друга, тем более, если вы начнете с DDD middle-out для общих концепций, а затем поработаете снаружи для деталей.Я чувствую, что выполнение этого процесса в обратном направлении приведет к гораздо большему количеству рефакторинга, чем необходимо, и гораздо более сложному рефакторингу, поскольку вы пытаетесь вытащить свой основной домен из коллекции связанных историй, которые, скорее всего, были разработаны в бункере.

5 голосов
/ 29 октября 2012

Мне посчастливилось пройти один из семинаров Гойко Адзича «Спецификация по примеру» в июне этого года.

Гойко ссылался на Эрика Эванса и ДДД на протяжении всего класса.

Момент лампочки для меня был, когда упражнение, которое мы выполняли, привело нас к рефакторингу модели предметной области «для более глубокого знания», то есть, когда мы получили более глубокое понимание предметной области, мы реорганизовали модель и вместе с ней тесты BDD. чтобы отразить это понимание.

Примером в классе была игра в блэкджек, где мы первоначально моделировали комбинацию карт как целое число, основанное на общей сумме карт. Когда мы пришли к более глубокому пониманию того, как работает игра «Блэкджек», мы ввели понятие руки, являющейся рукой «Блэкджек», поэтому отошли от использования целочисленного значения, чтобы представить руку, представляющую собой целочисленное значение или «Блэкджек». 'Рука.

В своей практике я стремлюсь развивать модель предметной области и ее вездесущий язык. Затем я использую этот вездесущий язык в своих тестах BDD.

1 голос
/ 22 августа 2011

Не понимаю, почему это не должно работать? BDD - это разработка, основанная на поведении, то есть в процессе разработки, которая может (должна) повлиять на ваш дизайн. DDD - это дизайн, управляемый доменом, и он больше касается общего дизайна вашей системы. Короче говоря, в BDD (или любом другом xDD) вы определяете, как что-то должно работать, и затем ваша задача - реализовать эти требования. Если вы реализуете эти требования с использованием DDD, или что-то еще не должно иметь значения ... вам все равно нужен зеленый знак рядом с этим тестом.

ОБНОВЛЕНИЕ: Я не думаю, что DDD - это направление, для меня DDD - это поддержание вашего кода в чистоте. Я бы сказал, что использование BDD - это способ помочь сохранить ваш код в чистоте, если вы начнете с простой реализации своего домена, вы можете получить слишком сложный домен. Я бы хотел использовать BDD для определения своих функций (например, функции входа в систему) и различных сценариев (например, успешного и неудачного входа в систему). После этого я не стал бы писать модульных тестов , поэтому у меня есть что-то, что проверяет код, а не поведение. Когда я это осуществлю, модульные тесты, надеюсь, пройдут и тест BDD. После этого наступает время рефакторинга, и во время рефакторинга все ваши тесты должны оставаться зелеными. Вы можете видеть это как два цикла, внешний цикл, который проверяет поведение (BDD), и один внутренний круг, который проверяет реализацию (TDD). Это должно не мешать вам использовать принципы DDD, вместо этого я бы сказал, что вам будет проще поддерживать ваш домен в чистоте и решать вашу актуальную проблему под рукой.

Обновление 2 (ссылки):

0 голосов
/ 13 июня 2014

Да, я считаю, что BDD и DDD могут использоваться вместе.Вот тестовая структура C #, которая может помочь в этом

http://kernowcode.github.io/UBADDAS/

...