Какие практики вы сейчас используете после прочтения о DDD?

Question

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

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

Answer 1

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

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

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

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

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

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

Answer 2

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

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

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

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