이벤트의 비 프리미티브 유형

Question

이벤트를 처리 할 때 사람들은 일반적으로 프리미티브로만 구성된 매우 간단한 값의 예를 사용합니다. 하지만 더 많은 정보가 필요한 이벤트는 어떻습니까? 이러한 경우를 처리 할 수있는 특정 구조를 만들 수 있습니까?

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

    public class Carriage 
    { 
     string Descrizione 
     int Quantity 
    } 
} 

캐리지 클래스는 이벤트 네임 스페이스의 일부이며 복잡한 논리 또는 기타 항목이 없습니다.

하지만 난 다른 이벤트가 있다면 :

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 라이브러리 만 공유하면되므로 최소한의 종속성이 있습니다.