На каком уровне проверки должны проводиться в основном в контексте DDD?

Question

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

Я спрашиваю о проверках в контексте доменного дизайна.

1. На каком уровне в основном должны проводиться проверки?
2. Допустимо ли, чтобы объект находился в недопустимом состоянии?потому что во многих ответах говорилось, что это нормально, и в основном из-за исторических данных, и бизнес-правила могут со временем меняться, а загрузка исторических данных может вызвать проблемы?
3. Многие реализации рассматривают создание исключений на уровне домена и отображение сообщений наПользовательский интерфейс, хотя Мартин Фаулер рекомендует Замена бросающих исключений с уведомлением в валидациях !Когда возвращать сообщения, а когда выбрасывать исключения в контексте проверки?

4. Во многих статьях объясняются некоторые советы или пути, которым следует следовать, например Владимир Хориков и jbogard inих статьи, но в комментариях они признаются, что теперь делают все по-другому.Эти шаблоны по-прежнему действительны?

5. Должен ли я использовать фреймворк, такой как FluentValidation и, если я его использую, эта каркасная работа используется только на прикладном уровне в качестве альтернативыMVC annotations?

6. Когда я должен использовать Business Rule Framework (BRF) вместо?

---

Я знаю много вопросов здесь, но они нацелены на одно и то же место (Проверка в DDD).

Примечание: я не использую шаблон CQRS, потому что он сделал приложение настолько сложным.Итак, у меня есть (domain layer,data layer, application layer(MVC), and shared kernel)

Answer 1

На каком уровне проверки должны выполняться в основном?

В основном в Домене, за исключением проверки, связанной с инфраструктурой, например, проверки xsd или схемы json.

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

Это может быть приемлемо, поскольку проверка выполняется в домене.не должно быть дела.С точки зрения бизнеса, объекты не могут находиться в недопустимом состоянии, однако иногда, как и в реальной жизни, процесс может находиться в недопустимом / временном состоянии.Мы называем это возможной последовательностью (https://en.wikipedia.org/wiki/Eventual_consistency),. Я предлагаю вам взглянуть на это. В конце система будет в допустимом состоянии, и это все, что имеет значение, если она временно недействительна, ну, усилия могут быть большечтобы поддерживать такую ​​систему, но иногда у вас нет выбора.

Многие реализации рассматривают выбрасывание исключений на уровне домена и отображение сообщений в пользовательском интерфейсе, хотя Мартин Фаулер рекомендует заменять выбрасывающие исключения на уведомления в валидациях!возвращать сообщения и когда выбрасывать исключения в контексте проверки?

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

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

Должен ли я использовать фреймворк, такой как FluentValidation, и, если я его использую, эта фреймовая работа используется только на прикладном уровне в качестве альтернативы аннотациям MVC?

Лучшие рекомендации в DDD - никогда не использовать фреймворк, однако Spring или JDBC могут помочь, но в целом вы должны делать это вручную.Мы даже написали магазины вручную, сервисы приложений и прогнозы Oracle и шину событий.Это быстрее, проще в обслуживании, и вы узнаете намного больше.Вон Вернон в своей книге (Внедрение доменного дизайна) приводит очень хорошие примеры и проект, на который вы можете посмотреть: https://github.com/VaughnVernon/IDDD_Samples (написано на Java)

Когда следует использовать Business Rule Framework(BRF) вместо этого?

Опять же, не используйте рамки

Answer 2

Есть прямые ответы на ваши вопросы.Поэтому я поставил ответы без фона.

На каком уровне в основном должны проводиться проверки?

Как на стороне сервера, так и на стороне клиента для более точных и безопасных приложений.Независимо от контекста дизайна.На стороне сервера вы можете использовать различные способы, такие как свободная проверка или аннотация данных (модель), или предоставить их клиенту с помощью библиотек интеграции, таких как jquery-unobtrusive-ajax. Проверка на стороне сервера более важна , так как операции CRUD должны быть проверены, чтобы избежать аномалий и т. Д. .... С точки зрения вашего вопроса, слоями являются Вид и Модель (Доступ к данным).

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

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

Многие реализации рассматривают выбрасывание исключений на уровне домена и сопоставление сообщений с пользовательским интерфейсом, хотя Мартин Фаулер рекомендует заменять выбрасывающие исключения на уведомления в валидациях!Когда возвращать сообщения, а когда выбрасывать исключения в контексте проверки?

Отображение исключения на стороне клиента - это хороший метод для дней разработки или для уведомления соответствующего пользователя об ошибке, которая препятствует изменению данных /сохраняются., учитывая, что : некоторые системы действительно не имеют никакой стратегии, чтобы показать дополнительную информацию конечному пользователю.Некоторые отчеты могут сделать приложение более уязвимым для вторжения.Это полностью зависит от типа программного обеспечения, которое вы разрабатываете.Хорошей практикой является показ простой ошибки на стороне клиента и хранение журналов ошибок внутри сервера (с подробными сведениями).

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

У некоторых людей могут быть личные архитектуры с собственными именами.Но некоторые из них являются официальными и широко используются, например, Unit Of Work или Repository Pattern , которые добавляют несколько слоев к известному шаблону (MVC) для достижения более точного, чистого и поддерживаемого кода / приложения.Следуйте основной цели любого шаблона.

Должен ли я использовать фреймворк, такой как FluentValidation, и, если я его использую, эта фреймовая работа используется только на прикладном уровне в качестве альтернативы аннотациям MVC?Когда я должен вместо этого использовать Business Rule Framework (BRF)?

FluentValidation является альтернативой DataAnnotations , работающей как FluentAPI .Обратите внимание, что оба используются для определения правил для свойств, принадлежащих определенному классу (таблица базы данных).Существует концепция с именем ViewModel , которая содержит преобразование (с некоторыми изменениями) для класса Main Model (таблица), в основном предназначенное для проверки в front-end.Вы можете использовать оба для проекта, сопоставляя каждую модель с ее ViewModel или наоборот.Если вы используете шаблон репозитория, скажем, у вас есть уровень доступа к данным, поэтому некоторая часть проверки находится внутри этого уровня.Если вы используете ViewModel, значит, он находится внутри уровня приложения.Но, как совет, они бесполезны.Ключевой успех состоит в том, чтобы понять основную цель любой техники / архитектуры / шаблона.Вы можете найти тонны статей вокруг каждого из них и сосредоточиться на цели, а затем решить, что делать, чтобы получить более чистый / стандартный / поддерживаемый / гибкий / и т. Д. Код.

И Заключительный совет : Увеличение модульности увеличивает стоимость интеграции (стоимость программного обеспечения), хотя снижает стоимость каждого модуля.Используйте умеренный дизайн для вашего проекта.Объединение архитектур иногда не только не является хорошей идеей, но также увеличивает стоимость и трудности разработки.Подробнее в Основы проектирования программного обеспечения

Answer 3

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

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

Часто эта проверка выполняетсяформа преобразования данных из сообщения в граф объектов значения в домене;обычно это выглядит как фабрики или разработчики, которые знают, как принимать независимые от домена типы значений и преобразовывать их в специфичные для домена значения.Модель домена обычно не знает ничего о формате сообщения и не знает о сериализации (обычно JSON не является проблемой домена).

Существует аналогичное разделение задач при чтении значений изпостоянное хранилище - фабрики значений будут знать, как создавать значения из примитивов, но не обязательно будут ничего знать о JSON, наборах результатов и т. д.

«Бизнес-логика», которая проверяет, является ли данныйсообщение имеет смысл , учитывая текущее состояние домена , обычно живет в модели домена.

Допустимо ли, чтобы объект находился в недопустимом состоянии?

Не допускается, чтобы объект находился в недопустимом состоянии.

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

Когда возвращать сообщения и когда выдавать исключения в контексте проверки?

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