Ответ 1
DDD не является архитектурой.
Это философия дизайна, вы не можете просто переименовать все свои FooDAO в FooRepositiories, выбросить слой Anti-Corruption и называть его DDD.
Речь идет о доменном дизайне. Он ставит акцент на модели, которые вы используете для решения проблем в вашем конкретном домене. Что предлагает Эрик Эванс, так это то, что если ваш сайт является просто формой для присоединения к списку рассылки, нет причин тратить дни перед доской, играя с моделями. Это мое мнение, если в вашем домене есть только один контекст, вам не нужен DDD. Подробнее об этом немного.
Там знаменитая цитата:
"В" Компьютерной науке "есть только две трудные проблемы: недействительность кэша и именование вещей". - Фил Карлтон
И у DDD есть шаблоны для решения этих проблем. Он предлагает ubitiquous язык в качестве шаблона для решения именования, и он предлагает часто ошибочную коллекцию шаблонов: репозиторий, агрегат, объект и объект Value для решения согласованности модели (в котором я буду использовать недействительность кэша и не буду здесь останавливаться).
Но я бы сказал, что, самое главное, он добавляет критический 3-й предмет (не выключенный 1 проблемой):
Где разместить вещи
Где поставить код и логику. Для меня самая фундаментальная концепция DDD - это контекст. Не все проблемы лучше всего обслуживаются одной и той же моделью, и знание того, где заканчивается один контекст, а другой начинается, является критическим первым шагом в DDD.
Например, в моей компании мы работаем с Джобсом, Работодателями и рекрутерами. Мир ищущего работу сильно отличается от мира рекрутера, и они оба смотрят на Работу по-разному. В качестве примера, в мире (контексте) рекрутеров они могут опубликовать работу и сказать
Я хочу, чтобы эта работа была доступна в Нью-Йорке, Остине и Сан-Франциско.
В OO говорят: у одного задания есть одно или несколько мест.
В мире ищущего работу работу в Лос-Анджелесе - это не то же самое, что работа в Бостоне. Nevermind, если они занимают одно и то же место в одной компании. Разница в физическом местоположении имеет смысл для ищущего работу. В то время как рекрутер хочет управлять всеми рабочими местами Widget Manager из одного места, даже если они распространены по всей стране, Jobseeker в Нью-Йорке не волнует, есть ли такая же позиция в Сиэтле.
Итак, вопрос? Сколько мест должно иметь Job? Один или много?
Ответ DDD - оба. Если вы находитесь в контексте jobseeker, то задание имеет только одно местоположение, и если вы рекрутер, в этом контексте задание может иметь много местоположений.
Контекст Jobseeker полностью отделен от контекста Recruiter и должен не делиться одной и той же моделью. Даже если в конце дня все задания попадают в одну и ту же БД (возможно, другой контекст), обмен моделями между контекстами может сделать модель валетом всех профессий и мастером ни одного.
Теперь этот пример очень специфичен для домена найма и поиска работы. Он не имеет ничего общего с Entity Framework ADO или MVC или ASP. DDD является агностиком.
И это DDD ересь, чтобы утверждать, что структура A или B делает вашу архитектуру DDD. Весь смысл DDD заключается в том, что модель должна удовлетворять потребности конкретного Контекста в пределах определенного Домена. Рамки могут поддерживать только это и сделать это возможным, они не могут делать:
$ dddonrails new MyDDDApplication
$ dddonrails generate context ContextA
$ dddonrails generate context ContextB
$ dddonrails generate model Widget ContextA
$ dddonrails generate model Widget ContextB
$ dddonrails start
Чтобы конкретно задать вопрос: "Для DDD? Или не для DDD?" Хорошая новость заключается в том, что вам не нужно принимать решение в начале, "Это будет проект DDD!" DDD не требует каких-либо инструментов, кроме желания серьезно подумать о проблемах, которые вы пытаетесь решить, и спросить, мой код помогает или причиняет мне боль?
Плохая новость - это DDD, требующая серьезной приверженности взглянуть и бросить вызов вашему дизайну, задавая каждый день "Является ли эта модель максимально упрощенной в этом контексте?"
Но отделите несколько тактические и практические проблемы того, что среда представления (MVC или нет MVC) и структура персистентности (Entity Framework?) от задачи моделирования вашего бизнес-домена. Если вы хотите начать сейчас, подумайте о том, какие контексты в вашем приложении. Некоторые вопросы:
- Являются ли несколько областей приложения решающими разные проблемы с одними и теми же базовыми данными?
- Сколько команд работает в приложении?
- Как они интегрируются друг с другом?
Отображение этих данных называется Рисование контекстной карты, и это важный первый шаг к началу DDD.
Я рекомендую вам еще раз проверить сайт ddd. Там есть хорошие видео Eric Evans на qcon. Вы также можете прочитать книгу Эрика Эванса "Управление доменными именами", у него есть еще много примеров.