DDD - это не архитектура.
Это философия дизайна, вы не можете просто переименовать все ваши FooDAO в FooRepositiories, добавить антикоррупционный слой и назвать его DDD.
Это означает доменно-управляемый дизайн.Он фокусируется на моделях, которые вы используете для решения проблем в вашей конкретной области.Эрик Эванс предполагает, что если ваш сайт - это просто форма для присоединения к списку рассылки, то нет причин проводить дни за доской, играя с моделями.По моему мнению, если в вашем домене только один контекст, вам не нужен DDD.Подробнее об этом чуть ниже.
Есть известная цитата:
«В информатике есть только две серьезные проблемы: аннулирование кэша и присвоение имен». - Фил Карлтон
И у DDD есть шаблоны для решения этих проблем.Он предлагает универсальный язык в качестве шаблона для решения имен, и предлагает часто неправильно истолкованную коллекцию шаблонов: Repository, Aggregate, Entity и Value Object для решения проблемы согласованности модели (о которой я расскажу о недействительности кэша и не буду здесь более подробно рассказывать).
Но я бы сказал, что самое важное, он добавляет критический 3-й предмет (не исключая 1 проблемы):
Куда положить вещи
Кудапоставить код и логику.Для меня самая фундаментальная концепция в DDD - это контекст .Не все проблемы лучше всего обслуживаются одной и той же моделью, и знание того, где заканчивается один контекст и начинается другой, является критически важным первым шагом в DDD.
Например, в моей компании мы работаем с Джобсом, соискателями и рекрутерами.Мир соискателя сильно отличается от мира вербовщика, и они оба по-разному смотрят на работу.Например, в мире (контекста) рекрутеров они могут разместить работу и сказать:
Я хочу сделать эту работу доступной в Нью-Йорке, Остине и Сан-Франсе.
В ОО говорят: одна работа имеет одно или несколько мест.
В мире соискателей работа в Лос-Анджелесе - это не то же самое, что работа в Бостоне.Не берите в голову, если они - то же самое положение в той же самой компании. Разница в физическом местоположении имеет значение для соискателя .В то время как рекрутер хочет управлять всеми заданиями Widget Manager из одного места, даже если они разбросаны по всей стране, ищущему работу в Нью-Йорке не важно, доступна ли такая же должность в Сиэтле.
Так что вопрос?Сколько мест должно быть у работы?Один или Много?
Ответ DDD - оба.Если вы находитесь в контексте соискателя , то у задания есть только одно местоположение, и если вы рекрутер , в этом контексте у задания может быть много мест.
Контекст Jobseeker полностью отделен от контекста рекрутера, и они не обязательно должны использовать ту же модель.Даже если в конце дня все задания окажутся в одной и той же БД (возможно, в другом контексте), совместное использование моделей между контекстами может сделать модель мастером на все руки и мастером ни одного.
Теперь этот пример очень специфичен для области найма и поиска работы.Это не имеет ничего общего с 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 , чтобы узнать больше. На qcon есть также несколько хороших видео Эрика Эванса. Возможно, вы также захотите прочитать книгу Эрика Эванса «Дизайн, управляемый доменом», у него есть еще много примеров.