DDD - модель устойчивости и модель домена

Я пытаюсь освоить доменно-ориентированный дизайн (DDD), и я думаю, что у меня есть основная идея. Но что-то меня смущает.

В DDD модели персистентности и модель предметной области разные вещи? Я имею в виду, что мы разрабатываем наш домен и классы с учетом только проблем домена; это нормально Но после этого, когда мы создаем наши репозитории или любую другую систему хранения данных, должны ли мы создать другое представление нашей модели для использования на уровне постоянства?

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

Просто останови это! Модель предметной области не является моделью постоянства

Если это правда, что было бы преимуществом наличия отдельных объектов персистентности из объектов домена?

Ответ 1

Подумайте об этом так, модель домена не должна зависеть от ничего и не иметь внутри нее кода инфраструктуры. Модель домена не должна быть сериализуема или наследоваться от некоторых объектов ORM или даже делиться ими. Это все проблемы, связанные с инфраструктурой, и их следует определять отдельно от модели домена.

Но, если вы ищете доступ к чистым DDD и масштабируемости и производительности проектов, которые будут превышать скорость первоначальной разработки. Много раз смешение инфраструктурных проблем с вашей "моделью домена" может помочь вам добиться больших успехов в скорости за счет масштабируемости. Дело в том, что вам нужно спросить себя: "Являются ли преимущества чистого DDD стоимостью затрат в скорости разработки?". Если ваш ответ "да", то вот ответ на ваш вопрос.

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

Это всего лишь один пример, но он показывает, почему ваша модель домена должна быть отделена от вашей модели сохранения. В этом примере вы не хотите разрывать классы вашей модели домена в соответствии с изменениями, внесенными вами в модель модели настойчивости, и существенно изменить смысл вашей модели домена. Вместо этого вы хотите изменить сопоставление между вашей новой моделью сохранения и моделью домена.

Существует несколько преимуществ для сохранения этих дизайнов, таких как масштабируемость, производительность и время реакции для изменений в чрезвычайных ситуациях, но вы должны взвесить их против стоимости и скорости первоначальной разработки. Как правило, проекты, которые получат наибольшую выгоду от такого уровня разделения, - это крупномасштабные корпоративные приложения.

ОБНОВЛЕНИЕ ДЛЯ КОММЕНТАРИЙ

В мире разработки программного обеспечения существует N-е число возможных решений. Из-за этого существует косвенная обратная связь между гибкостью и начальной скоростью развития. В качестве простого примера я мог бы жестко программировать логику в классе, или я мог бы написать класс, который позволяет вводить в него динамические логические правила. Первый вариант имел бы более высокую скорость разработки, но ценой более низкой степени гибкости. Последний вариант имел бы более высокую степень гибкости, но ценой более низкой скорости разработки. Это верно для каждого языка кодирования, поскольку всегда существует N-е число возможных решений.

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

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

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

Ответ 2

В DDD, модели персистентности и модели домена разные?

Да, но это не обязательно означает, что другой набор классов явно отображает модель персистентности.

При использовании реляционной базы данных для персистентности ORM, такой как NHibernate, может заботиться о представлении модели персистентности посредством сопоставлений классам домена. В этом случае нет явных классов модели сохранения. Успех такого подхода зависит от возможностей отображения ОРМ. Например, NHibernate может поддерживать класс промежуточного сопоставления через сопоставление компонентов. Это позволяет использовать явный класс модели сохранения, когда возникает необходимость.

Если вы используете базу данных документов для сохранения, обычно существует еще меньше потребности в модели персистентности, поскольку модель домена должна быть сериализована только для того, чтобы ее можно было сохранить.

Следовательно, используйте явный класс модели persistence, когда есть сложное отображение, которое невозможно достичь с помощью сопоставлений ORM для модели домена. Разница между моделью домена и моделью сохранения сохраняется независимо от реализации.

Ответ 3

В DDD, модели персистентности и модели домена разные?

В DDD у вас есть модель домена и репозиторий . Это оно. Если внутри репозитория вы сохраняете свою модель домена напрямую или преобразовываете ее в модель персистентности, прежде чем продолжать, это зависит от вас! Это вопрос дизайна, вашего дизайна.

Как утверждают другие участники, у каждого варианта есть свои плюсы и минусы. Взгляните на этот ответ, где я подробно изложу некоторые из них.