DDD или старая мода?

Question

Мы собираемся разработать сайт для бронирования автомобилей Rentacar, используя asp.net. Существует изменение в том, что приложение будет масштабироваться, и мне было интересно, что, если использование DDD поможет в обслуживании и производительности. Мне было интересно, что, если появятся новые подобные сайты, разработанные с использованием наборов данных и SP или DDD. Значит, мои друзья в DDD или по старинке?

Answer 1

Как и вы, я нахожусь в процессе создания нового проекта, и я выбрал DDD-путь, который, я уверен, лучше, чем «старомодный» способ (отделенный и лучше тестируемый) ... Но я должен признать, что я борюсь с некоторыми вопросами и не всегда могу найти ответы ... даже на stackoverflow.com

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

Наконец, я думаю, что проекты сообщества S # arp Architecture являются очень хорошим местом для обучения, и задают вопросы .

Answer 2

"интересно, что если использование DDD поможет в обслуживании и производительности."

В этом может помочь куча вещей. TDD / BDD, IoC, хороший OR / M, такой как NHibernate (с FluentNHibernate для конфигурации) ...

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

Но правильно сделанный, DDD может дать вам чистый и ясный код: процедурный код спагетти старого запада исчезнет, ​​и вам будет легче перемещаться по собственной базе кода. Рефакторинг может иметь место (и становится намного менее страшным).

Лично - я бы никогда не прикоснулся к другой "старой школе" кодовой базе, и, конечно, я бы не начал новый проект таким образом. Дайте мне новый проект, и я собираюсь попросить ReSharper, NHibernate, FluentNHibernate и StructureMap. И это все, что мне нужно ....

Answer 3

Да, можно создавать сайты, которые также хорошо работают с DDD. Цель DDD - позволить домену быть вашей моделью вождения. В настоящее время в нашем проекте мы использовали NHibernate в качестве объекта Relational Mapper в верхней части домена. Это работает очень хорошо, особенно потому, что NHibernate также поддерживает разные вещи для повышения производительности, такие как кэш второго уровня. Списки объектов, которые должны быть загружены из базы данных для 10000+ пользователей, нуждаются только в одном запросе, и разные сессии будут использовать один и тот же memcache. Поэтому, если вы используете ORM, убедитесь, что вы используете эти преимущества кэша!

Следует также учитывать, что для каждого цикла выпуска вашего программного обеспечения вы не только обновляете программное обеспечение (модель домена), но также должны позаботиться об обновлении базы данных при изменении модели вашего домена. Однако это не отличается от необходимости обновлять StoredProcs.

Кстати: даже при использовании DDD и ORM все равно будут проблемы, для которых вы могли бы предпочесть использовать SP. Пример: создание нового номера заказа. Если на вашем веб-сайте более 10000 пользователей, а многопользовательские пользователи хотят создать новый заказ, вы должны убедиться, что все номера заказов остаются уникальными. Мы обнаружили, что мы предпочитаем, чтобы SP делали такие блокирующие вещи выше ORM.

Если у вас теперь есть шанс попробовать DDD, обязательно попробуйте. Удачи.

Answer 4

На мой взгляд, DDD хорош для больших сайтов, созданных с помощью ASP.NET MVC. Однако я предупреждаю, что платформа ASP.NET MVC все еще относительно незрелая. Если вы решите использовать DDD, то я предлагаю вам рассмотреть ASP.NET MVC, TDD и шаблон репозитория в качестве своего сочетания технологий. Если вы используете стандартную WebForm, я бы не предложил DDD. Если вы используете SP, то DDD действительно не очень хорош, поскольку вы не можете использовать шаблон Repository, поскольку он опирается на GetAll, GetByID, Insert, Update, Delete ... и вы расширяете их с помощью фильтров, реализованных в LINQ с использованием IQueryable. ... хорошо, если вы используете SP, то вы должны отменить все преимущества этой структуры. Просто мой взгляд.