Является ли DDD пустой тратой времени?[закрыто]

Question

Поиск в Google "Для каких приложений подходит DDD?" дал мне следующий ответ:

Вероятно, 95% всех программных приложений попадают в категории “не очень хорошо подходит для использования DDD”.(см . статья)

Так из-за чего весь сыр-бор?!?

Приложение, над которым я работаю, является главным образом ориентирован на данные, но все же содержит некоторую бизнес-логику и правила, которые необходимо применять.Будет ли пустой тратой времени начинать применять методы DDD?Лучше ли мне использовать более традиционный уровень доступа к данным, модель POCOs и уровень бизнес-логики?Или сформулировать это по-другому - что является надежной альтернативой DDD?

Answer 1

Многие разработчики, которые считают, что DDD полезен для их проекта, попадают в ловушку, полагая, что вся их работа заключается в написании кода.Это не тот случай.Работа разработчика заключается в реализации функциональности, чтобы проблему можно было решить с помощью программного обеспечения.Это приводит к выводу, что написание кода - это не начало того, что делает разработчик, а конец:код является результатом всего процесса, ПРЕДШЕСТВУЮЩЕГО фактическому написанию кода.

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

Проблема с "как DDD работает на практике" и "может ли кто-нибудь привести мне пример того, как я пишу код с помощью DDD?" и тому подобное на самом деле проистекает из того факта, что люди, задающие такого рода вопросы, сосредоточены на написании кода, но понятия не имеют, ПОЧЕМУ они пишут ЭТОТ код, а не другой код.Ввод в эксплуатацию.:если вы понимаете, что DDD - это определение ТОГО, ЧТО вы должны написать в качестве функциональности и ПОЧЕМУ, все становится на свои места.КАК вы будете писать этот код, решать вам.Но , как было сказано:это уже не самая большая проблема, поскольку к тому времени вы уже знаете, что вам нужно написать и почему.

Answer 2

вы знаете, иногда 5% зарабатывают больше денег, чем все остальные 95% - вот почему существует DDD.

это для конкретной сложной большой системы.

Answer 3

Извините, но если бы DDD был всего лишь способом мышления, как говорит Франс Боума, то он не рекомендовал бы такие вещи, как Постоянное Невежество.Это отвергает других как разработчиков несколько низшего класса.

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

Но решить, идти по пути PI или нет, само по себе непросто, и вы не можете обзывать кого-то ("программиста"), если он чувствует себя неловко по этому поводу.

Возьмите ERP-пакет с повсеместным интерфейсом, подобным MS Access:таблицы с текущими итогами, автообновляющимися столбцами и прокруткой без страниц для 100 000 записей.Очевидно, что подход DDD подходит для того, чтобы подумать о том, как работать с этим приложением.Но за многие годы я ни разу не видел никого - ни в книгах, ни в Интернете, хотя бы подтвержденных доказательствами объяснений, не говоря уже о реальных примерах кода, о том, как PI мог бы справиться с этим вездесущий ситуация для всех, кто хочет доставить приложения коммерческого класса и пользовательский опыт.

Не хочу впадать в религиозность по этому поводу.Сторонники DDD и DAL, как правило, чрезмерно религиозны и могут оттолкнуть тех, кого однажды укусили, но у кого есть / были открытые взгляды.Многие просто хотят встретиться лицом к лицу с реальным жизненным опытом (т.е.ПОДУМАЙТЕ), и вас не будут обслуживать только Кошками, Автомобилями и базовыми Заказами (т.е.плохой КОД) для поддержки проповеди.

Answer 4

Вот очень похожий вопрос: Разрешаете ли вы веб-уровню получать прямой доступ к DAL?

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

Answer 5

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

Answer 6

Если вы прочтете статью еще немного, то увидите следующее:

Для 5% приложений, где DDD хорошо подходит, это очень хорошая подгонка.В таких ситуациях DDD поможет вы расколете очень крепкий орешек.Здесь DDD может быть серебряной пулей для этого оборотня, на которого ваш менеджер только что указал вам на стол.

Вот почему вокруг этого такой ажиотаж.

Answer 7

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

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

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

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