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

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.