Что делает мой код DDD (доменный дизайн) квалифицированным?

Question

Я новичок в DDD и думаю об использовании этой техники дизайна в моем проекте.

Однако, что меня поразило в DDD, так это то, что основная идея. В отличие от других методов проектирования, таких как MVC и TDD, он, похоже, не содержит каких-либо основополагающих идей.

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

Для меня единственная новой идеи в DDD, вероятно

• «Smart» сущности (т.е. вы должны иметь бизнес-правила на корневых агрегатах)
• Разделения между объектом значения, корневой агрегатом и юридические лица.

Может ли кто-нибудь сказать мне, если я пропустил что-нибудь здесь? Если это все, что нужно для DDD, если я обновляю одно из существующих приложений MVC с помощью вышеуказанных двух новых идей, могу ли я утверждать, что это приложение TDD, MVC и DDD?

Answer 1

Короткий ответ заключается в том, что это не то, что выглядит ваш код, который квалифицирует его как проект DDD, так вы достигли этого кода. Теперь для длинной версии ...

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

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

Answer 2

DDD на самом деле не является контрольным списком - это методология.

В дополнение к Stefans ответ, я хотел бы предложить следующее (в порядке важности):

• Повсеместный язык - Есть ли ваш код использовать одни и те же имена/термины как бизнеса? Используют ли ваши объекты домена те же названия, что и бизнес?
• Поведение - Является ли большинство поведения/логики связанными непосредственно с объектами домена или у вас много немых DTO?
• Ограниченные контексты - У вас есть четкое определение области ответственности и Разделение проблем?
• Агрегаты - Вы идентифицировали Агрегаты на основе корневых объектов и стратегии блокировки для обеспечения соблюдения бизнес-инвариантов?
• Хранилище - это все данные доступа/запрашивая сделан через репозиториев, или у вас есть код SQL в других классах?
• Domain Services - У вас есть Доменные службы для бизнес-логики, которая, естественно, не подгонку в объекте домена
• Спецификации - У вас есть бизнес-правила, красиво завернутые в спецификации?
• Query Specifications - У вас есть предварительно спроектированные запросы/фильтры красиво обертка в спецификациях запросов?

Тогда есть все остальное!

Я думаю, что большинство практиков DDD хотели бы сказать:

"Я работаю с предметной области, чтобы понять их потребности и писать системы, которые (а) соответствуют условия и процессы бизнеса, (б) помочь другим разработчикам понимают бизнес-домен и (c) могут сгибать, чтобы соответствовать изменяющимся требованиям бизнеса. «

Надеюсь, что это поможет!