search

tpierrain / CQRS

A simple project to explain CQRS during a live coding session at MS experiences'16
142 stars 32 forks source link

"Muscle" the domain part #1

Open tpierrain opened 8 years ago

tpierrain commented 8 years ago

Indeed, the current solution has a pretty anemic domain ;-(

Even if the objective is to explain CQRS pattern, I would also like to have a nice example of real domain logic vs. infra code.

It sounds pretty logical to me to have such kind of anemic domain on the read-side, but I really like to have more complex / interesting domain code on the write-side.

It would be nice to have some feedback from hotel/booking reservation domain experts.

MendelMonteiro commented 8 years ago

I'm not a domain expert but surely the state of the rooms (reserved or not) can at the very least checked when a booking request command arrives. Currently two clients can both get the same list of 'available' rooms and book the last room at the same time. There is no failure scenario when DeclareRoomBooked for the same room is executed twice.

I would rather see the graph of domain objects be kept in the write model so that the write validation path can be implemented as simply as possible. Currently the PlacesAndRoomsRepository stores the state of the rooms but does so in perhaps a way that it optimised for the read model. There is no harm in storing the same data twice if it's to be used for two different purposes.

tpierrain commented 8 years ago

You're absolutely right. So far I've only implemented the minimum viable happy path scenarii ;-)

Thanks for your feedback. I'll integrate all of it tomorrow (I'm currently trying to understand how ASP.NET core works so that I can have an MVP web app to demonstrate the usage).