-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Thoughts on CQRS vs CRUD for these services #20
Comments
@gbengataylor this might be a good Q for you. I know you've been thinking about this a lot recently... |
I think as we start to expand on some of the features CQRS may be beneficial if there is a need to decouple reads from writes. For e.g, the search service - the "write" api for search may be different from the "read" (the read may need to return denormalized or aggregated data). Rather than doing the transformation on the read, it may make sense to have separate data representations for each operation
|
I want to document decisions made in the architecture and provide a spot to debate - thus this issue.
CRUD was a simple v1 choice because it's easy to implement but as we grow some services might be better served by a CQRS model. I'm hesitant initially because of the added complexity. There are no plans to add eventing (KNative) into this demo repo.
Microservices.io Pattern ref
Martin Fowler link
The text was updated successfully, but these errors were encountered: