Что делает мой код DDD (доменный дизайн) квалифицированным? - PullRequest
7 голосов
/ 25 мая 2010

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

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

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

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

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

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

Ответы [ 2 ]

14 голосов
/ 26 мая 2010

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

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

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

7 голосов
/ 26 мая 2010

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

Помимо ответа Стефана, я бы предложил следующее (в порядке важности):

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

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

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

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

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

...