DDD: руководство по обновлению нескольких свойств объектов

Question

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

Пусть я сущность

public class EventOrganizer : IEntity 
{ 
    public Guid Id { get; } 

    public string Name { get; } 

    public PhoneNumber PrimaryPhone { get; } 

    public PhoneNumber AlternatePhone { get; private set; } 

    public Email Email { get; private set; } 

    public EventOrganizer(string name, PhoneNumber primaryPhoneNr) 
    { 
     #region validations 

     if (primaryPhoneNr == null) throw new ArgumentNullException(nameof(primaryPhoneNr)); 

     //validates minimum length, nullity and special characters 
     Validator.AsPersonName(name); 

     #endregion 

     Id = new Guid(); 
     Name = name; 
     PrimaryPhone = primaryPhoneNr; 
    } 
}  

Моей проблема: предположит, что это будет конвертирована и поданный на просмотр MVC, и пользователь хочет обновить AlternatePhone, электронную почту и множество других свойств, которые имеют смысл существовать внутри этого объекта для данного ограниченного контекста (не показано для краткости).

Я понимаю, что правильный руководство должно иметь метод для каждой операции, но (И я ЗНАЮ ЕГО КИНДА АНТИ-ПАТТЕРНЫ), я не могу помочь, но если это не приведет к запуску нескольких вызовов обновления в базе данных.

Как это обрабатывается? где-то вниз по линии, будет ли что-то, что сопоставляет мой EventOrganizer с чем-то - скажем DbEventOrganizer и собирает все изменения, внесенные в объект домена, и применяют их в один проход?

Answer 1

DDD лучше подходит для пользовательских интерфейсов на основе задач. То, что вы описываете, очень ориентировано на CRUD. В вашем случае отдельные свойства рассматриваются как независимые поля данных, в которых один или многие из них могут быть обновлены одной общей бизнес-операцией (обновлением).

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

Зачем кому-то обновлять все эти поля? Какая неявная бизнес-операция - это попытка пользователя достичь этого? Есть ли более конкретный бизнес-процесс, который выражается путем изменения PrimaryPhone, AlternatePhone и Email?

Возможно, это изменение ContactInformationEventOrganizer? Если это так, вы можете моделировать одну операцию ChangeContactInformation на EventOrganizer. Ваш пользовательский интерфейс затем отправит команду ChangeContactInformation, а не команду update.

Что касается сохранения ваших основных корней (AR), это обычно обрабатывается ORM, например NHibernate, если вы используете РСУБД. Однако существуют другие способы сохранения ваших AR, таких как Event Sourcing, NoSQL DB и даже storing JSON или любые другие форматы обмена данными в СУБД.

Answer 2

У вас вопрос довольно широкий!

Сам EventOrganizer ничего не должен обновлять. Вы должны сохранить код обновления совершенно отдельно от объекта. Другой класс будет принимать объект EventOrganizer и обновлять БД. Это называется «постоянством невежества» и делает код намного более модульным и сплоченным.

Было бы обычным создать View Model - класс, целью которого является предоставить представление с точными данными, которые ему нужны, в нужную ему форму. Вам нужно будет создать View Model из EventOrganizer, после чего View может обновить ее - программно или с привязкой. Когда вы будете готовы сохранить изменения, вам необходимо обновить EventOrganizer с помощью View Model и передать его в программу обновления. Это похоже на слой, который вам не нужен, когда проект мал и прост, но он становится неоценимым по мере сборки сложности.