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

Сначала для некоторого фона, Martin Fowler на самом деле описал три различных "шаблона" в своей книге Шаблоны Предприятия Arcitecture. Сценарий транзакции, Активная Рекордная и Модель предметной области. DDD использует шаблон модели предметной области для полной архитектуры и описывает много методов и шаблонов, чтобы реализовать и разработать эту модель.

сценарий Транзакции является архитектурой, где у Вас нет разделения на уровни. Та же часть кода читает/пишет базу данных, обрабатывает данные и обрабатывает пользовательский интерфейс.

Активная Запись, каждый повышается от этого. Вы отделяете свой UI, Ваша бизнес-логика и слой данных все еще живут вместе в активных рекордных объектах, которые смоделированы после базы данных.

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

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

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