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

Для тех, кто действительно увлекается DDD, как это изменило вашу практику разработки?

5
Kye 21 Июл 2010 в 14:45

2 ответа

Лучший ответ

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

Несколько вещей, которые изменились для меня после того, как я быстро прочитал Domain Driven Design Quick:

Теперь я определяю совокупные корни, сущности и типы значений.

Я использовал шаблон репозитория вместе с nHibernate для реализации уровня сохраняемости. (Это потому, что мне кажется, что этот ORM хорошо подходит для реализации границ агрегатов)

Я приветствую использование повсеместного языка, на который вы уклоняетесь (вероятно, самое важное изменение, которое я сделал).

Помимо этого, DDD просто формализовал то, что я считал здравым смыслом.

3
danielfishr 31 Окт 2010 в 03:16
Это может вас заинтересовать, если вы еще этого не видели - ayende.com/Blog/archive/2009/04/17/…
 – 
RichardOD
22 Июл 2010 в 13:42
+1 Не могу полностью согласиться с вашим ответом. Я не работаю с .Net, но все остальное применимо. Чтобы эффективно применять DDD, вы должны осознавать свой собственный опыт при обсуждении каждой темы, а книга Эвана - ценный инструмент для переосмысления тех тем, с которыми вы уже сталкиваетесь в реальных проектах.
 – 
JuanZe
4 Авг 2010 в 18:41

Не совсем ответ на ваш вопрос, но ...

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

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

Если вы находитесь в положении, когда кто-то другой создает точные требования, а вы кодируете решение, тогда отлично. Но если вы находитесь в положении, когда вы должны понимать требования (и вы не эксперт в области бизнеса), то основная суть DDD < em> может изменить ваш подход.

1
Vijay Patel 24 Июл 2010 в 20:45