Действительно ли DDD является пустой тратой времени? [закрытый]
Козу можно создать только с помощью ключевого слова 'new'. После того, как козел создан, вы можете дать его кушать тигру. Итак, этот козел здесь
void hunt(Goat food) {
System.out.println(name + " ate " + food.name);
}
уже создан, поэтому вам не нужно создавать его снова. Конечно, вы можете инициировать его снова, но это было бы бессмысленно, поскольку если бы тигр сам мог создать козу, ему не нужно было бы охотиться на коз.
6 ответов
Многие разработчики, которые думают, что DDD полезен для их проекта, попадают в ловушку, поскольку они думают, что их работа заключается в написании кода. Это не тот случай. Работа разработчика заключается в реализации функциональности, поэтому проблему можно решить с помощью программного обеспечения. Это приводит к выводу, что написание кода - это не начало того, что делает разработчик, а конец: код - это результат всего процесса ДО того, как код действительно будет написан.
DDD не о написании кода, это не 10-шаговый процесс «под ключ», чтобы получить отличное программное обеспечение, а весь процесс, прежде чем код будет написан, это понимание того, в чем заключается проблема, что / кто участвует, в каких информационных потоках и как эти элементы выглядят, как они связаны друг с другом и т. д. и т. д. Фактически, наиболее важной частью DDD является создание языка, который делает возможными беседы между экспертами в области и разработчиками без неправильной интерпретации . Это «вездесущий язык», о котором говорит Эванс. По сути, это делает весь процесс ДО написания кода процессом, который мало что дает для угадывания, все понятно и понятно. (это цель).
Проблема с «как DDD работает на практике» и «может ли кто-нибудь дать мне пример того, как я пишу код с DDD?» и подобное на самом деле исходит из того факта, что люди, задающие подобные вопросы, сосредоточены на написании кода, но понятия не имеют, ПОЧЕМУ они пишут этот код, а не другой код. Иу: если вы понимаете, что DDD - это открытие ЧТО вы должны написать как функциональность и ПОЧЕМУ, все встанет на свои места. Как вы пишете этот код, решать только вам. Но, как сказано: это больше не самая большая проблема, так как вы к тому времени уже знаете, что вы пишете и почему.
DDD - это программное обеспечение, которое будет поддерживаться некоторое время. Для меня это означает, что он должен выражать идеи, которые будут меняться с доменом. Несомненно, простое приложение может быть идеальным для короткого времени доставки и короткого времени реализации. Однако, если вам нужно развивать программное обеспечение, принципы DDD очень помогут. DDD может быть непростым делом, но как только вы поймете вездесущий язык и проблемы с разделением, все станет легко.
Вот очень похожий вопрос: Разрешаете ли вы веб-уровень получать прямой доступ к DAL?
Я использую DDD для всех своих проектов. В небольших приложениях некоторые концепции не применяются, но я считаю, что многие аспекты применимы ко всем проектам независимо от их размера.
Если вы немного больше прочитаете статью, вы увидите это:
Для 5% приложений, где DDD хорошо подходит, это очень хорошо подходит. В таких ситуациях DDD поможет Вы ломаете очень крепкий орешек. Здесь, DDD может быть серебряная пуля для этого оборотень, что твой менеджер просто указал на ваш стол.
Вот почему суета об этом.
вы знаете, иногда 5% приносят больше денег, чем все остальные 95% - вот почему существует DDD.
это для конкретной сложной большой системы.
Поскольку ваше приложение в основном ориентировано на данные, возможно, ваша архитектура может быть в основном традиционной.
Для тех аспектов, где у вас больше логики и потенциальных объектов предметной области или значений, возможно, вы могли бы использовать некоторые идеи DDD для организации кода.
В общем, «разумная альтернатива» состоит в том, чтобы все было максимально просто. возможно, используйте концепции DDD там, где это полезно, и не усложняйте излишне вещи, как советует статья.
Сейчас я начинаю аналогичный проект, он представляет собой сочетание обработки данных и дополнительных областей, управляемых логикой / алгоритмами. Точно так же я хотел бы выделить те части DDD, которые принесут пользу проекту, но не пытаться навязывать его тем областям, где это может быть контрпродуктивным.