1

In my current Monolithic application using EventSourcing and CQRS with Java, we have a seperate write and read models.

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.
}

In above Command and Event classes, command model class "Address" has been shared between them. I am thinking above is not correct, instead seperate Address classes should be created for each Read and Write model. By using above approach, are we violating like seperation of concerns principle? and what other real issues do we really face if we share same Command models between Command and Event classes. Please let me know whether I am thinking correct or wrong..

john
  • 925
  • 1
  • 12
  • 20

1 Answers1

2

I think you are off the mark here.

CreateEmployee and EmployeeCreated are in memory representations of messages; these messages are a part of your API surface. If your CreateEmployee schema and the EmployeeCreated schema share the same understanding of Address, then you are not likely to run into problems if you also share the same data structure.

Put another way, the same constraints that you are thinking to apply to Address would also apply to simpler things like CustomerId; yes, you can have more than one representation of CustomerId in your model, but what advantage do you get from that?

There are places where multiple representations of the same broad idea can make sense: for example an UnverifiedAddress and a VerifiedAddress are two different things.

In some cases, it will make sense for the consumer of a message to use a different in memory representation than the producer does - your read model might use a different in memory representation than is used by the write model. Similarly, it may make sense for different consumers to have different in memory representations of the same idea.

The trivial version of this is when you are dealing with consumers implemented in different languages. Not likely to come up when you are working with a monolith.

VoiceOfUnreason
  • 52,766
  • 5
  • 49
  • 91
  • hi, at first thanks for your explanation. But my query is: sharing command model into Event classes seems not be better approach. since Events output and Command input might vary, right? Whats the best practise? Seperate models should be created for each Command and Event classes? or can be shared without any problem at all? doesnt matter whether our app is monolithic or Microservices – john Aug 04 '20 at 07:11