Ответ 1
Подумайте об этом так, модель домена не должна зависеть от ничего и не иметь внутри нее кода инфраструктуры. Модель домена не должна быть сериализуема или наследоваться от некоторых объектов ORM или даже делиться ими. Это все проблемы, связанные с инфраструктурой, и их следует определять отдельно от модели домена.
Но, если вы ищете доступ к чистым DDD и масштабируемости и производительности проектов, которые будут превышать скорость первоначальной разработки. Много раз смешение инфраструктурных проблем с вашей "моделью домена" может помочь вам добиться больших успехов в скорости за счет масштабируемости. Дело в том, что вам нужно спросить себя: "Являются ли преимущества чистого DDD стоимостью затрат в скорости разработки?". Если ваш ответ "да", то вот ответ на ваш вопрос.
Начните с примера, когда ваше приложение начинается с модели домена, и так получилось, что таблицы в базе данных точно соответствуют вашей модели домена. Теперь ваше приложение растет с большой скоростью, и вы начинаете испытывать проблемы с производительностью при запросе базы данных. Вы применили несколько хорошо продуманных индексов, но ваши таблицы растут настолько быстро, что похоже, что вам может потребоваться де-нормализация базы данных, чтобы не отставать. Таким образом, с помощью dba вы придумали новый дизайн базы данных, который будет отвечать вашим потребностям в производительности, но теперь таблицы значительно отличаются от того, как они были до этого, и теперь фрагменты ваших объектов домена распространяются на несколько таблиц чем одна таблица для каждого объекта.
Это всего лишь один пример, но он показывает, почему ваша модель домена должна быть отделена от вашей модели сохранения. В этом примере вы не хотите разрывать классы вашей модели домена в соответствии с изменениями, внесенными вами в модель модели настойчивости, и существенно изменить смысл вашей модели домена. Вместо этого вы хотите изменить сопоставление между вашей новой моделью сохранения и моделью домена.
Существует несколько преимуществ для сохранения этих дизайнов, таких как масштабируемость, производительность и время реакции для изменений в чрезвычайных ситуациях, но вы должны взвесить их против стоимости и скорости первоначальной разработки. Как правило, проекты, которые получат наибольшую выгоду от такого уровня разделения, - это крупномасштабные корпоративные приложения.
ОБНОВЛЕНИЕ ДЛЯ КОММЕНТАРИЙ
В мире разработки программного обеспечения существует N-е число возможных решений. Из-за этого существует косвенная обратная связь между гибкостью и начальной скоростью развития. В качестве простого примера я мог бы жестко программировать логику в классе, или я мог бы написать класс, который позволяет вводить в него динамические логические правила. Первый вариант имел бы более высокую скорость разработки, но ценой более низкой степени гибкости. Последний вариант имел бы более высокую степень гибкости, но ценой более низкой скорости разработки. Это верно для каждого языка кодирования, поскольку всегда существует N-е число возможных решений.
Доступны многие инструменты, которые помогут вам увеличить начальную скорость разработки и гибкость. Например, инструмент ORM может увеличить скорость разработки для вашего кода доступа к базе данных, а также предоставить вам гибкость в выборе любых конкретных реализаций баз данных, поддерживаемых ORM. С вашей точки зрения, это чистая прибыль как за время, так и за гибкость за вычетом стоимости инструмента (некоторые из которых являются бесплатными), что может или не может быть вам стоить на основе стоимости времени разработки относительно стоимости деловые потребности.
Но для этого разговора в стилях кодирования, который по сути является тем, чем управляется Driven Design, вам нужно учитывать время, необходимое для написания этого инструмента, который вы используете. Если вы должны написать этот инструмент ORM или даже написать логику доступа к базе данных таким образом, чтобы он поддерживал все реализации, которые предоставляет вам этот инструмент, это займет гораздо больше времени, чем если бы вы просто жестко кодировали конкретную реализацию, которую вы планируете при использовании.
Таким образом, инструменты могут помочь вам компенсировать собственное время производства и цену гибкости, часто путем распределения стоимости того времени всем, кто покупает этот инструмент. Но любой код, включая код, который использует инструмент, будет по-прежнему влиять на соотношение скорости и гибкости. Таким образом, Domain Driven Design обеспечивает большую гибкость, чем если бы вы объединили свою бизнес-логику, доступ к базе данных, доступ к сервисам и код пользовательского интерфейса вместе, но за счет затрат времени на производство. Domain Driven Design предлагает приложения уровня предприятия лучше, чем небольшие приложения, потому что приложения уровня предприятия имеют более высокую стоимость для первоначального времени разработки в отношении стоимости бизнеса и потому что они более сложны, они также более подвержены изменениям, требуя большей гибкости при снижение затрат во времени.