Почему я не могу смоделировать свой домен с помощью ERD?

Question

Я довольно новичок в этом обсуждении, но я должен задать этот вопрос, даже рискуя казаться "невежественным". Почему сейчас мы так много внимания уделяем «DDD»? Чем больше я смотрю на «DDD», тем сложнее выглядит мое заявление. Принимая во внимание, что моделирование моего домена с помощью базы данных помогает поддерживать согласованность моего приложения на разных уровнях. Затем я могу использовать помощники DAL, такие как SubSonic или L2S, чтобы легко получить доступ к этой модели. Что в этом плохого? Даже в корпоративных приложениях?

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

Я готов услышать от пуристов здесь.

Answer 1

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

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

Там действительно приходит время, чтобы сделать ход. Как будто я не буду делать ООП со структурами и указателями на функции. ; -)

Answer 2

На самом деле это действительно отличный вопрос, и краткий ответ: «Вы можете». Мы привыкли делать это таким образом, и существовала целая область моделирования предприятия (данных). Фактически, общие обозначения OOD произошли от ERD.

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

OOD в значительной степени проистекает из желания упростить поиск структуры кода, обладающей несколькими желаемыми свойствами:

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

Простота продумывания дизайна происходит от Simula, которая использовала то, что мы сейчас называем «объектами» для моделирования; в симуляции было удобно иметь программные объекты, которые соответствуют вещам, которые вы моделируете. Только позже Алан Кей и его коллеги из Xerox увидели в этом более общий метод структурирования.

У части, касающейся устойчивости к изменениям, было много родителей, но одним из наиболее важных среди них был Дейв Парнас, вы написали несколько работ, которые определили основное правило для модульности, которое я называю Законом Парнаса: каждый модуль должен сохранять секрет, и этот секрет - требования, которые могут измениться.

Оказывается, что, комбинируя Закон Парнаса с идеей Симулы о «объекте», соответствующем чему-то, что может быть отождествлено с реальным миром, вы стремитесь получить конструкции систем, которые являются более надежными В соответствии с требованиями изменений, чем старый способ, которым мы делали вещи. (Не всегда, и иногда вам нужно быть хитрым, как в случае с шаблоном Command . Большинство объектов являются существительными, то есть имеют постоянное существование. В шаблоне Command идеальными объектами являются глаголы вещи, которые вы делаете .)

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

Answer 3

Краткий ответ: если все, что вам нужно, это система CRUD, которая позволяет пользователям редактировать данные, просто создайте клиентский интерфейс Access для вашей серверной базы данных (или используйте каркас поддержки, как вы упомянули) и назовите его на день. Вы должны иметь возможность сэкономить 70% своего бюджета по сравнению с доменной системой.

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

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

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

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