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

Question

Я использую CQRS.Везде, где я читаю, говорится, чтобы я помещал логику проверки в объекты команд.Например, см. Эту ссылку: https://lostechies.com/jimmybogard/2016/04/29/validation-inside-or-outside-entities/

См. Приведенную ниже команду (взято из ссылки):

public class ChangeNameCommand { 
   [Required] 
   public string FirstName { get; set; } 
   [Required] 
   public string LastName { get; set; } 
 } 

и бизнес-объект ниже (также взято из ссылки - примечание.что я изменил параметр, передаваемый конструктору Customer из класса в интерфейс):

public class Customer 
{ 
   public string FirstName { get; private set; } 
   public string LastName { get; private set; } 

   public void ChangeName(IChangeNameCommand command) { 
     FirstName = command.FirstName; 
     LastName = command.LastName; 
   } 
 } 

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

public class ChangeNameCommandWithoutValidation : IChangeNameCommand { 
   public string FirstName { get; set; } 
   public string LastName { get; set; } 
 } 

и затем передать команду (без валидации) объекту домена.,В этом случае я считаю, что Доменный объект не имеет никакого контроля над тем, что ему передается?

Поэтому я должен идти вразрез со всеми указаниями, которые я могу найти, и выполнить проверку в доменном объекте?Я считаю, что я должен сделать это, потому что команды находятся в отдельной библиотеке классов для объектов домена.Правильно ли я понял это?

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

Answer 1

Несколько мыслей:

• Сообщение в блоге, на которое вы ссылаетесь, сбивает с толку, поскольку оно приравнивает валидацию к инвариантам.

  В литературе DDD инварианты чаще всего ссылаются на правила домена, которые применяются в корневой сущности и нигде больше.Что касается валидности domain , то, как вы выразились, «не все указания» предназначены для обеспечения их выполнения на командной стороне - скорее наоборот.Популярные школы мысли считают, что сущность всегда должна быть действительной и, следовательно, должна заботиться о своих собственных правилах (или инвариантах).

  Тип достоверности, о котором говорят образцы в посте Джимми Богардас другой стороны, находится на границе между допустимостью домена и допустимостью ввода пользователя.Я бы не стал устанавливать каменное правило, чтобы ставить такую ​​проверку на одну или другую сторону.Хотя вполне справедливо считать, что это действительно работа для Команды, с некоторыми системами типов вы можете прекрасно кодировать такого рода ненулевые ограничения в типах свойств сущностей, и было бы стыдно не использовать эту свободную дополнительную корректность.

• Как уже было сказано в комментариях, размещение интерфейса над командой кажется странным.

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