2013-12-09 2 views
1

Я хотел бы остановиться на этом вопросе When to update audit fields? DDD.Как обновить поля проверки в модели домена?

В моей модели домена, и это может быть не подходящее место для нее, но у нас есть свойство для CreateBy и ModifiedBy, оба типа User, оба объекта значения.

Я новичок в DDD и смущен, на каком уровне отвечает за обновление этих свойств ... Данные? Домен? или приложение?

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

Вот пример моего класса ...

public class SpritePalette 
{ 
    private readonly SpritePaletteColors _colors; 

    public string Id { get; private set; } 
    public string Name { get; private set; } 
    public SpritePaletteColors Colors { get { return _colors; } } 
    public bool IsPublic { get; private set; } 
    public User CreatedBy { get; private set; } 
    public DateTime CreatedDate { get; private set; } 
    public User ModifiedBy { get; private set; } 
    public DateTime ModifiedDate { get; private set; } 

    public SpritePalette(
     string name) 
    { 
     this.Name = name; 
     this.IsPublic = false; 

     _colors = new SpritePaletteColors(); 
    } 

    internal void UpdateId(string value) 
    { 
     Validate.IsNotEmpty(value, "Id is required."); 

     this.Id = value; 
    } 

    public void UpdateName(string value) 
    { 
     this.Name = value; 
    } 

    public void MarkAsCreated(User value) 
    { 
     this.CreatedBy = value; 
     this.CreatedDate = DateTime.UtcNow; 
    } 

    public void MarkAsModified(User value) 
    { 
     this.ModifiedBy = value; 
     this.ModifiedDate = DateTime.UtcNow; 
    } 

    public bool HasColor(string color) 
    { 
     return _colors.HasColor(color); 
    } 

    public void AddColor(string color) 
    { 
     _colors.AddColor(color); 
    } 

    public void RemoveColor(string color) 
    { 
     _colors.RemoveColor(color); 
    } 

    public void UpdateIsPublic(bool value) 
    { 
     this.IsPublic = value; 
    } 
} 

Я работник два метода, один для маркировки модели, как созданные, которая обновляет CreatedBy и CreatedDate, и аналогичный метод для маркировки модели как изменено.

Насколько это приемлемо, когда дело доходит до DDD? Каков лучший способ справиться с обновлением свойств аудита, подобных этим? Есть ли лучший способ, т. Е. Использование событий?

Я признаю, что это немного субъективно, но будет признателен за любую помощь, которую любой может предложить!

ответ

1

Solutions с «рамкой»

А. разоблачить каждый конструктор и командный метод с дополнительными параметрами. как:

public SpritePalette(
    string name, User user) 
{ 
    this.Name = name; 
    this.IsPublic = false; 

    _colors = new SpritePaletteColors(); 
    createdBy(user) 
} 

public void UpdateName(string value, User user) 
{ 
    this.Name = value; 
    modifiedBy(user); 
} 

internal void modifiedBy(User value) 
{ 
    this.CreatedBy = value; 
    this.CreatedDate = DateTime.UtcNow; 
} 

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

//application layer 
public void update(String name, String description, ....other attributes,User user) [ 
    //retrieve SpritePalette 
    SpritePalette.updateName(name, user); 
    SpritePalette.updateDescription(description, user);//passes user again 
    //other command methods invocation //passes user again & again 
} 

B. разоблачить дополнительный аудит полей метод обновления.

Как:

//application layer 
public void update(String name, String description, ....other attributes,User user) [ 
    //retrieve SpritePalette 
    SpritePalette.updateName(name); 
    SpritePalette.updateDescription(description); 
    //other command methods invocation 
    SpritePalette.modifiedBy(user); 
} 

Но я боюсь, что иногда мы можем забыть вызвать этот метод ModifiedBy().

решение без «рамок»

Может быть, мы должны использовать другие наборы моделей. Что делать, если мы моделируем поведение обновления как события? В базовом домене не требуются поля аудита. Поля для аудита обычно необходимы по запросу, например: «Я хочу видеть, кто изменяет вещь».

Давайте разделим их:

class UpdateNameEvent { 
    string SpritePaletteId; 
    string name; 
    User user; 
    Date when; 
} 

class SpritePalette{ 
    on(UpdateNameEvent event) { 
     this.Name = event.name();//no user involved 
    } 
} 

//application layer 
public void update(String name, User user) [ 
    //retrieve SpritePalette 
    var event = new UpdateNameEvent(name, user); 
    SpritePalette.on(); 
    //other command methods invocation 
    events.save(event); //save the events 
    repository.update(SpritePalette); 
} 

public List<SpritePaletteEvent> list(string id) { 
    return events.list(id); 
} 
1

В вопросе вы связаны выше, CreatedBy и UpdatedBy являются частью домена слоя, так как в реальных встречах домена фактически запланированном кем-то.

В вашей настройке (Sprites) кажется маловероятным, что CreatedBy и UpdatedBy действительно являются частью основного графического домена.Следовательно, свойства CreatedBy/UpdatedBy предназначены только для ведения бухгалтерского учета и аудита и, следовательно, представляют собой проблему с чисто уровнем приложений, и их следует обрабатывать только на уровне приложения. В Java вы обычно обновляете эти флаги некоторым Interceptor, но я не уверен, как вы можете это сделать на C#. Возможно, можно обновить эти поля в репозитории (разрешив приложению зарегистрировать текущего пользователя в единице работы или аналогичном).

Смежные вопросы