-
Notifications
You must be signed in to change notification settings - Fork 464
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
Request: Unit of Work pattern #3
Comments
Well, you should not do that actually in the level of the repository 😉 We will touch it in the article about aggregates and transactions, but tl;dr is that it should be done by events and should be asynchronous. If it needs to be transactionally consistent it should be one entity (or actually aggregate according to DDD nomenclature). Stay tuned 😉 |
Looking forward to that follow-up. Isn't this also done with Saga pattern, invoking multiple commands? PS. I noticed that the frequency of blog articles dropped off a bit. I ❤️ loved the ones you wrote already. Thank you! So much better than the usual Hello World shallowness of these articles. Do you still plan to finish the series? |
Hey @aschrijver! I'm really glad you liked the series. We took a short break by the end of the year, but we're back on the track now. :) We're now finishing the "refactoring" stage (I've recently added tests in https://threedots.tech/post/microservices-test-architecture/ and Robert will post another article soon). Then, we will move to more advanced stuff, like strategic patterns. We also plan to add new features to the application in a totally new form. :) |
Would be very interesting see your take on how to use the repository pattern when you need to make changes across different entities/domains.
I read about Unit of Work, that basically means implementing an intermediate in-memory structure that does trasaction-commit-rollback at the application level, without having a dependency on the underlying database.
The text was updated successfully, but these errors were encountered: