Непримитивные типы в событиях

Question

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

namespace Events { 
    public class BlueTrainCleaned 
    { 
     Datetime start 
     Datetime end 
     Carriage[] Carriages 
    } 

    public class Carriage 
    { 
     string Descrizione 
     int Quantity 
    } 
} 

Класс Carriage является частью пространства имен событий и не имеет сложной логики или чего-то еще.

, но если у меня было еще одно событие:

public class RedTrainCleaned 
{ 
    Datetime start 
    Datetime end 
    Carriage[] Carriages 
} 

Перевозка будет частью интерфейса второго события также. Если скажем 40 или 50 событий с одним и тем же «объектом значения события», это означает, что мой проект будет сильно связан с этим объектом. Это не выглядит так хорошо для меня, но что я могу сделать, чтобы этого избежать? Это предупреждение, что что-то в анализе моего домена не очень хорошо сделано?

спасибо за вашу помощь,

Answer 1

Я думаю, это зависит от того, как стандарт Carriage находится в вашем домене. Если он меняется для одного события, должен ли он измениться и для других?

Думаю, я думаю о примере Address. Это довольно стандартно в домене, и я думаю, что имеет смысл включить это в объект моего события, если я поднимаю событие, содержащее адресную информацию. Таким образом, если станет известно, что нам нужно иметь расширение ZIP + 4 для моего почтового индекса, я могу добавить новое поле в мой класс Address и иметь это свойство для будущих событий. Я могу внести изменения в одно место и предоставить его для будущих событий.

Если Carriage может означать что-то другое на разных событиях, то, возможно, это не то, что вы должны включить, - и вместо этого сгладить его в своем случае. Но если Carriage действительно является вездесущим определением в вашем домене, то я думаю, что это хорошо, чтобы включить его в свои классы событий.

Насколько это может быть неприятно слышать, я думаю, что это действительно «зависит».

Надеюсь, это поможет. Удачи!!

Answer 2

отдельный проект библиотеки классов могут быть созданы, чтобы содержать классы сообщений (DTO-х). Этот проект идеально не должен зависеть от других проектов решения, и он должен содержать только сериализуемые POCO. В этом случае будет минимальная зависимость, так как вам нужно только поделиться библиотекой DTO.