Когда следует использовать разработку на основе домена и разработку на основе базы данных?

Question

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

Answer 1

Во-первых, Мартин Фаулер описал три различных «шаблона» в своей книге «Шаблоны корпоративной архитектуры». Сценарий транзакции, активная запись и модель предметной области. DDD использует шаблон модели предметной области для всей архитектуры и описывает множество практик и шаблонов для реализации и проектирования этой модели.

Сценарий транзакции - это архитектура, в которой нет слоев. Этот же фрагмент кода читает / записывает базу данных, обрабатывает данные и обрабатывает пользовательский интерфейс.

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

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

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

Множество инструментов упрощает решения, основанные на данных. В пространстве Microsoft очень просто визуально создавать веб-сайты, где весь код находится прямо за веб-страницей. Это типичное решение для сценария транзакции, и оно отлично подходит для простого создания простых приложений. В Ruby on rails есть инструменты, облегчающие работу с активными объектами записи. Это может быть причиной для управления данными, когда вам нужно разработать более простые решения. Для приложений, где поведение важнее, чем данные, и трудно определить все поведение, так как сначала DDD - это путь.

Answer 2

Думайте об этом так.

Проблемная область существует вечно. Ваши определения классов будут отражать вечные свойства домена.

Реляционная база данных сегодня является предпочтительным механизмом сохранения. В какой-то момент мы пройдем мимо этого к чему-то «более новому», «лучше», «другому». Дизайн базы данных - это всего лишь одна реализация; он отражает архитектуру решения больше, чем проблемную область.

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

Answer 3

Я задал похожий вопрос: С чего начать проектирование при использовании O / R-сопоставления? Объекты или таблицы базы данных?

Из ответов, которые я получил, я бы сказал: если у вас нет конкретной причины использовать разработку на основе баз данных, используйте разработку на основе доменов.

Answer 4

Как примечание к посту Менделя, я чувствую, что есть четвертый паттерн: многоуровневый, отделяющий бизнес-логику от постоянства и хранения, но не использующий «сущностей» или «бизнес-объектов». Половина пути, если хотите, между сценарием транзакции / действия и DDD.

В большинстве систем, над которыми я работал, уровень персистентности (репозитории) напрямую использовал SqlClient и возвращал наборы данных вызывающей службе. Сервисы выполняли решения и компилировали представления, которые отправлялись пользователю через контроллер. Теперь вы считаете, что сервисный уровень является бизнес-моделью, и вы были бы правы, но это не была «доменная» модель в смысле DDD. Тем не менее, ВСЕ бизнес-логика произошла в этом одном слое, период. У каждого слоя была своя работа. Представления отображали данные, определяемые контроллерами представления, хранилище, обрабатываемое на уровне постоянства, и службы работали между контроллерами и постоянством.

Дело в следующем: DDD - это подход к определению бизнеса с помощью Ul, тестов и кода. Это не о сущностях, объектах стоимости и агрегатах. Эти вещи являются лишь побочными продуктами пуристического подхода ООП к DDD.

Просто больше мыслей на ваше рассмотрение.

Answer 5

Для сложных бизнес-моделей я предпочитаю сочетание ActiveRecord и DDD. Объекты домена знают, как сохранить себя, и действия с данными выполняются с хранилищем (nHibernate может выступать в качестве универсального хранилища, если вы смотрите на хранилище как на то, что предоставляет данные модели в виде коллекции). Бизнес-логика находится в доменных объектах, и даже некоторая инкапсуляция типов значений может быть достигнута, хотя только при наличии бизнес-необходимости. Некоторые реализации DDD предпочитают удалять все общедоступные сеттеры и модифицировать сущности только через методы. Я не фанат этой реализации, если в этом нет особой бизнес-потребности.

Мне кажется, что эта реализация упрощает использование ActiveRecord и инкапсуляцию бизнес-логики DDD.

Answer 6

Разработка, управляемая доменом - это, безусловно, верный путь. это имеет больше смысла и добавляет гибкости.