Классы модели команд, общие для классов Command и Event в CQRS - PullRequest
Новая
       259

Классы модели команд, общие для классов Command и Event в CQRS

1 голос
/ 02 августа 2020

В моем текущем приложении Monolithi c, использующем EventSourcing и CQRS с Java, у нас есть отдельные модели записи и чтения. 

package com.command;
class Address{ //class created in Command Write model
   String address;
} 

package com.command;
import com.command.Address;
class CreateEmployeeCommand { //Command class belongs to Write Model
  Address address; //this is correct
}


package com.events;
import com.command.Address;
class EmployeeCreatedEvent { //Event class belongs to Read Model
 Address address; //this should not be correct IMO, instead seperate Address class should be created in event package.
}

В приведенных выше классах Command и Event класс модели команды "Address" "было поделено между ними. Я думаю, что приведенное выше неверно, вместо этого следует создавать отдельные классы адресов для каждой модели чтения и записи. Не нарушаем ли мы принцип разделения проблем, используя вышеуказанный подход? и с какими другими реальными проблемами мы действительно столкнемся, если будем использовать одни и те же модели команд для классов Command и Event. Пожалуйста, дайте мне знать, правильно я думаю или нет ..

1 Ответ

2 голосов
/ 02 августа 2020

Я думаю, вы здесь ошиблись.

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

Другими словами, те же ограничения, которые вы думаете применить к Address, также применимы к более простым вещам, таким как CustomerId; да, в вашей модели может быть более одного представления CustomerId, но какое преимущество вы получите от этого?

Есть места, где несколько представлений одной и той же общей идеи могут иметь смысл: например, UnverifiedAddress и VerifiedAddress - это две разные вещи.

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

Тривиальная версия этого - когда вы имеете дело с потребителями, реализованными на разных языках. Маловероятно, что вы будете работать с монолитом.

...