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

Я недавно наткнулся на это мнение от 2016 года, сказав, что в базе данных все еще есть основания для логики домена.

Я думал, что это полностью устарело. Мне просто интересно, если парень все еще живет в 90-х или это действительно может быть правдой. Отложить в сторону устаревшие системы.

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

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

Взять, к примеру, блог Чистого кодирования Боба Мартина. Как общее наблюдение, я нахожу сочинения Боба Мартина довольно ясными и ясными, поэтому меня сбивает с толку то, что люди постоянно смущаются тем, что он пишет, такими как принципы SOLID. Они зациклены на том, какой должна быть «Единая ответственность», или почему какой-то класс нарушает принципы Лискова, когда они, вероятно, должны делать просто пытаться написать лучший код и сначала получить некоторый опыт, чтобы то, что они читают в блоги имеют некоторый контекст.

По сути, вы говорите, что база данных должна содержать таблицы и данные, и это все, что она должна содержать. Но базы данных уникально подходят для выполнения определенных задач, которые ... ну, базы данных хороши.

В статье приводятся следующие вещи:

• Целостность данных и проверка (например, нулевые и уникальные ограничения)
• Безопасность на уровне строк
• Написание API с использованием хранимых процедур
• Расчет остатков
• Задавать вопросы базы данных (т.е. запросы и отчетность)
• Как избежать проблем с ORM, таких как N + 1

как подходящие вещи для внесения в базу данных. Я согласен с ним.

Причины, по которым вы не помещаете бизнес-логику (в целом) в базу данных:

• Блокировка поставщика
• Ваша база данных не является центральной властью
• Ваша команда не мыслит реляционно
• Низкая оснастка.

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

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

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

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

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

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

Мой личный взгляд:

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

С другой стороны, кто сказал, что база данных не может иметь поведение? Я создал офисные базы данных с помощью Filemaker. Люди называют это базой данных, но это действительно целая среда разработки приложений. Все без проблем интегрировано в одну и называется базой данных.

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

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

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

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

Наше приложение OO концепции безопасности состоит из ролей и групп. И оба являются рекурсивными структурами. Мы написали хранимую процедуру, которая разрешает права пользователя для объекта домена.

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