Как реализовать проверку сущности в экземплярах одной и той же сущности

В нашем проекте мы используем DDD как архитектуру (чистая архитектура). Скажем, у меня есть объект под названием A. У A есть свойство под названием B. Теперь мне нужно подтверждение того, что при создании второго объекта A этот объект B должен быть уникальным для всех экземпляров A в магазине.

Моя идея заключалась в том, чтобы реализовать для него сервис домена, используя репозиторий. Тогда возникает вопрос, должна ли эта служба домена реализовывать саму проверку или просто предоставлять для нее эти данные ... (которые будут использоваться в интеракторе / сценарии использования для проверки).

Пример кода (код остается простым):

public class A
{
   public A(string b)
   {
      B = b;
   }

   public string B {get; private set;}
}

Если честно, то, что вы показывали, совсем не clean :) у вашей модели есть конструктор. Но, несмотря на дебаты с точки зрения точки зрения, эту работу лучше делегировать основополагающей структуре. Например. при кодировании в хранилище памяти создайте Dictionary<string, object> и просто добавьте ключи для всех значений B. Словари в C# не допускают дублирования ключей. При кодировании с использованием базы данных реализуйте уникальное ограничение. При хранении в плоских файлах сделайте это задачей класса, который записывает реальные файлы.

zaitsman 13.07.2018 16:47

Конструктор не чистый? Почему не так чисто? Это лучший способ создать объект со всеми необходимыми (обязательными) полями.

Patrick Peters 13.07.2018 20:17
Стоит ли изучать PHP в 2023-2024 годах?
Стоит ли изучать PHP в 2023-2024 годах?
Привет всем, сегодня я хочу высказать свои соображения по поводу вопроса, который я уже много раз получал в своем сообществе: "Стоит ли изучать PHP в...
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
В JavaScript одним из самых запутанных понятий является поведение ключевого слова "this" в стрелочной и обычной функциях.
Приемы CSS-макетирования - floats и Flexbox
Приемы CSS-макетирования - floats и Flexbox
Здравствуйте, друзья-студенты! Готовы совершенствовать свои навыки веб-дизайна? Сегодня в нашем путешествии мы рассмотрим приемы CSS-верстки - в...
Тестирование функциональных ngrx-эффектов в Angular 16 с помощью Jest
В системе управления состояниями ngrx, совместимой с Angular 16, появились функциональные эффекты. Это здорово и делает код определенно легче для...
Концепция локализации и ее применение в приложениях React ⚡️
Концепция локализации и ее применение в приложениях React ⚡️
Локализация - это процесс адаптации приложения к различным языкам и культурным требованиям. Это позволяет пользователям получить опыт, соответствующий...
Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
3
2
298
2
Перейти к ответу Данный вопрос помечен как решенный

Ответы 2

Let's say I have an entity called A. A has a property called B. Now I want a validation that when a second entity A is created, that B must be unique over all instances of A in a store.

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

Простой ответ: вы вводите индекс, который отслеживает сопоставление каждого значения B с конкретным объектом A, которому разрешено владеть им.

Конечно, это вызывает разногласия; вам нужно смягчить ситуацию, когда два разных A модифицируются одновременно. Индекс и все элементов A становятся частью единой границы согласованности, которой необходимо управлять. Это в значительной степени то, что происходит, когда мы храним наши объекты в одной СУБД - мы можем ввести ограничение, чтобы гарантировать отсутствие дубликатов.

Вы можете разделить эту единую границу согласованности на отдельные объекты A, а также на отдельные объекты B-> A. Но теперь у вас есть возможная проблема, связанная с попыткой изменить две разные границы согласованности одновременно, и это создает условия гонки.

Третья возможность - ослабить ограничение согласованности - позволить сохранять конфликты и разрешать их позже. См., Например, Грега Янга на складские системы и Уди Дахана на условия гонки.

Обычный ответ от - очень сильно оттолкнуть это требование, чтобы убедиться, что оно реально: каковы фактические затраты для бизнеса в случае нарушения ограничения?

Подумайте о схемах сидений в самолете: очевидно, что на сиденье должен сидеть только один пассажир. Но это не означает, что место назначенный более чем для одного человека является критическим отказом, потому что операторы-люди (агенты ворот) имеют способы смягчить эти проблемы. См. Также выступление Грега Янга Остановить инженерное дело.

Это в значительной степени покрывает все варианты. Я бы посоветовал решать проблемы раньше, чем позже. Речь пойдет о клиентском опыте (UX или реальной жизни). Я предпочитаю получать уведомления о проблемах с сиденьями, когда сижу перед компьютером, чем в аэропорту: P --- если это не будет проблемой при добавлении уникального индекса / ограничения, тогда иди по этому пути. Если вы делатьвременно разрешаете нарушение, вам следует попытаться устранить его как можно скорее. Например, сразу после первоначального захвата может быть этап проверки.

Eben Roux 14.07.2018 08:39
Ответ принят как подходящий

Я думаю, что вариант с доменной службой - это вариант, взгляните на этот блог (blog.sapiensworks.com/post/2017/08/23/…), где дается сценарий «имя пользователя должно быть уникальным», похожий на мою проблему в начальный пост.

Другие вопросы по теме