В нашем проекте мы используем DDD как архитектуру (чистая архитектура). Скажем, у меня есть объект под названием A. У A есть свойство под названием B. Теперь мне нужно подтверждение того, что при создании второго объекта A этот объект B должен быть уникальным для всех экземпляров A в магазине.
Моя идея заключалась в том, чтобы реализовать для него сервис домена, используя репозиторий. Тогда возникает вопрос, должна ли эта служба домена реализовывать саму проверку или просто предоставлять для нее эти данные ... (которые будут использоваться в интеракторе / сценарии использования для проверки).
Пример кода (код остается простым):
public class A
{
public A(string b)
{
B = b;
}
public string B {get; private set;}
}
Конструктор не чистый? Почему не так чисто? Это лучший способ создать объект со всеми необходимыми (обязательными) полями.
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 --- если это не будет проблемой при добавлении уникального индекса / ограничения, тогда иди по этому пути. Если вы делатьвременно разрешаете нарушение, вам следует попытаться устранить его как можно скорее. Например, сразу после первоначального захвата может быть этап проверки.
Я думаю, что вариант с доменной службой - это вариант, взгляните на этот блог (blog.sapiensworks.com/post/2017/08/23/…), где дается сценарий «имя пользователя должно быть уникальным», похожий на мою проблему в начальный пост.
Если честно, то, что вы показывали, совсем не
clean
:) у вашей модели есть конструктор. Но, несмотря на дебаты с точки зрения точки зрения, эту работу лучше делегировать основополагающей структуре. Например. при кодировании в хранилище памяти создайтеDictionary<string, object>
и просто добавьте ключи для всех значенийB
. Словари в C# не допускают дублирования ключей. При кодировании с использованием базы данных реализуйте уникальное ограничение. При хранении в плоских файлах сделайте это задачей класса, который записывает реальные файлы.