Недостатки доменного дизайна?

Question

У меня может возникнуть глупый вопрос по поводу DDD: есть ли вообще какие-либо недостатки DDD?Я имею в виду, помимо использования, когда это не нужно, или необходимо.(например, небольшие / не сложные проекты)

Спасибо

Answer 1

Эрик Эванс сказал в презентации JavaOne, что DDD лучше всего подходит, когда существует лот сложности бизнес-домена.Более того, он прямо заявляет, что DDD не подходит для задач, которые имеют существенную техническую сложность , но , которая имеет небольшую сложность бизнес-области.Примером последнего является встроенная система с очень простыми входами (возможно, не зависящими от количества состояний, которыми она обладает), в то же время представляющая большую техническую сложность (с точки зрения обеспечения работы оборудования).

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

- редактировать -

Я получил видеопрезентацию через Emule, и я никогда не могнайдите ту же лекцию на YouTube или аналогичных видео-площадках.

Answer 2

Это очень легко сделать неправильно.

Answer 3

Мне показалось, что это обсуждение DDD в Руководстве по архитектуре приложений Microsoft помогает понять проблемы этого конкретного стиля:

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

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

Answer 4

На итальянской конференции я говорил о теме (см. эти слайды ).

Проекты DDD требуют привлечения экспертов по предметной области, которые зачастую дороги для найма, поскольку они обладают ценными знаниями (читай, если вам не нужен эксперт по предметной области, вам не нужен DDD).
Кроме того, DDD требует сильных навыков на стороне моделиста. В частности они должны быть:

1. Смиренный, поскольку они должны принять свое невежество и учиться у эксперта
2. Действительно опытный в ООП
3. Добросовестный, так как они должны отслеживать решения
4. Comunicative, так как они должны объяснить домен другим разработчикам (даже с помощью документации)

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

Answer 5

Мартин Фаулер в своей книге "PoEA" подробно обсуждает, когда и что шаблонам логики предметной области использовать.

Например, самый простой шаблон, Сценарий транзакции , не использует модель домена.