0

Так думаю, что у меня есть такого рода событий домена:Доменные События - наследование или использование перечислений

class BookChangedName... 
class BookType1ChangedName extends BookChangedName... 
class BookType2ChangedName extends BookChangedName... 

в том, что лучше или:

class BookChangedName{ 
    enum bookType = BOOK_TYPE_1; 
} 

Поскольку они говорят, что использовать наследование только если есть другое поведение между классами, я предполагаю, что я бы пошел с примером перечисления (case # 2) - поскольку Domain Events - это просто простые DTO.

Но опять же, в моем домене это разные типы событий имеют различное значение (разные пути обработки). Таким образом, в случае, я использую пример # 1 я бы в конечном итоге с большим количеством:

if(event instanceof BookType1ChangedName){ 
    //do smth in domain 
} 
else if(event instanceof BookType2ChangedName){ 
    //do smth in domain 
} 

, а также я не мог быть столь же явно, как:

when(BookType1ChangedName event){... 

я должен был бы сделать какой-то предварительно -переработка как:

@EventHandler(matcher_pattern = event->event.bookType==BOOK_TYPE_1) 
when(BookChangedNameevent){... 
+0

Если ваши типы книг являются разными агрегатами, может быть с одним родителем, если вы используете наследование, вы можете использовать одно и то же событие и иметь обработчики в базовом классе. –

ответ

0

имен событий являются важной частью в DDD (фактически любое «имя» имеет важное значение), поэтому я предлагаю использовать разные имена событий для различных событий, так как эти имена носят много информации. Кроме того, если вы используете код типа (с enum), вы увеличиваете индекс CRAP из-за дополнительных if.

0

У вас должно быть только одно событие BookChangedName и свойство BookType для этого события. Обработчик/подписчик события должен позаботиться о логике.

+2

Какова причина этого заявления? – plalx

+0

Это похожие события BookChangedName, BookType1ChangedName, BookType2ChangedName и т. Д. Вместо того, чтобы создавать разные классы событий для каждого типа книги, просто пусть обработчик события реализует способ обработки каждого типа книги. Обработчик может использовать шаблон стратегии, поэтому ему не нужно иметь дело с операциями if/else. – alltej

2

Используют ли ваши специалисты по домену фразу «BookType1»? Вы сказали, что для каждого типа книги существуют разные логические пути - я бы предложил опросить рациональное для этого, и, возможно, для каждого события существует более доменное имя? Попробуйте и послушайте язык, используемый экспертами домена, чтобы описать две ситуации.

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

С другой стороны, если это на самом деле просто booktype1 и booktype2 и в будущем, возможно, booktype3 и booktype4, я бы рассмотреть либо перечисление или даже просто целое число, и рассмотреть возможность реализации различных логических путей в различных стратегий и обработчик событий домена использует завод, чтобы вернуть соответствующую стратегию для данного типа книги, а затем делегировать стратегию для выполнения логики.