Great course with very knowledgeable and eloquent author, he explained a lots of different topics in about 2 hours which is very appreciated. Thanks Piotr!
At 1:51:18 it could be described as "your boundary of concerns is when the message is sent to the message broker/queue". What a great course, thank you! I feel that what you present on this channel is one level higher than Uncle Bob's lectures.
Hi Piotr... Thanks for sharing your knowledge with us ..... As always great and very useful content :) May the force be with you and Modular Monolith with us :D
First of all, I would like to congratulate you on the excellent content. I have a question about the vertical slice part. At the beginning of the video, you said that one difference between the classical and the modular monolith is that in modular you should use the vertical slice approach. But on the npay solution itself, the Wallets module use separated layers representing the responsibilities. My view on vertical slices is that you can have all these layers into a single 'slice' or a single layer, am I wrong about this perspective?
Excellent, perfect, although I hate Nuget for shared projects (prefer Git submodules although they too introduce some challenges), plus I am wary of all the support calls for data loss you can get with event-driven if the solution becomes microservices.
How is atomicity handled in the event driven system. For instance, creating a user should create a wallet but how do we deal with the case where after the user is stored in the db, there is an outage so the wallet isn't created?
At first, you need to make use of the Outbox pattern to ensure the guaranteed delivery of the events (and Inbox to ignore the potential duplicates). If you need more than that, such as some kind of orchestration on top of multiple modules, Saga might be helpful. It's pretty much the same when working with the microservices :) Check out our more advanced project for more building blocks github.com/devmentors/Inflow
@@DevMentorsEN How would you go about implementing the Outbox pattern? Would you use transaction log tailing, polling or something else? This is the biggest smell of EDA for me, relying on transaction log tailing feels kind of hacky but there seems to be no better alternative, at least not one that i'm aware of.
@@khuiification outbox can be tricky indeed - in our sample, in the main solution for Inflow project, we simply commit the events to be published to the DB using the same TX as for our domain models. However, when you think about scaling, this could easily result in sending the same events multiple times - thus you might think either of some smart partitioning, distributed locking (e.g. redis) or other approaches that could handle such cases.
Great video. I see however that modules are using same(shared) IoC container. Kamil Grzybek once done modular monolith where each module has it's own IoC container. What do you think about such approach? Pros/cons? Maybe you can extend your modular course with such variant as well?
Yes, you could certainly do it e.g. using Module type built into Autofac container, but in the end, it all boils down to the question, whether you really need it, and what's the benefit? As long as you keep using abstractions, and the implementations within each module are marked as internal types, etc. it's not really a game-changer (IoC module) or so :)
The upcoming course will be a comprehensive one, about 20 hours long, with a much more sophisticated domain and in-depth topics regarding e.g. event-driven architecture and all its challenges, microservices transition, etc. :)
Thank you DevMentors! Your channel is Majorly underrated! Great job!
Thanks, started working on a brand new content to change it at some point :)
Love you guys, great job as always. I'm really grateful you are doing this.
You're welcome :)
Great course with very knowledgeable and eloquent author, he explained a lots of different topics in about 2 hours which is very appreciated.
Thanks Piotr!
At 1:51:18 it could be described as "your boundary of concerns is when the message is sent to the message broker/queue". What a great course, thank you! I feel that what you present on this channel is one level higher than Uncle Bob's lectures.
This is excellent! Thank you DevMentors
Hi Piotr... Thanks for sharing your knowledge with us ..... As always great and very useful content :) May the force be with you and Modular Monolith with us :D
Thanks!
Damn good stuff, Sir. Smashing video. Thank you!
Thanks for the course!
Excellent content! Very useful! Thanks a lot!
Thanks. Great work as always. Keep it up guys. Good luck and thanks for sharing your knowledge.
Thank you :)
you are awesome, thank you for this video.
Awesome content, thank you for sharing
Thanks for the great material!
You're welcome!
First of all, I would like to congratulate you on the excellent content. I have a question about the vertical slice part. At the beginning of the video, you said that one difference between the classical and the modular monolith is that in modular you should use the vertical slice approach. But on the npay solution itself, the Wallets module use separated layers representing the responsibilities. My view on vertical slices is that you can have all these layers into a single 'slice' or a single layer, am I wrong about this perspective?
When the next mini course is coming?
Excellent, perfect, although I hate Nuget for shared projects (prefer Git submodules although they too introduce some challenges), plus I am wary of all the support calls for data loss you can get with event-driven if the solution becomes microservices.
thank you very much for this
Awesome video, finally some high quality enterprise software engineering insights and not only this high level shit one will find most of the time!❤️🔥
You mean you’re wanting to develop something that’s not just a todo list? 😮
Great Content, transitioning to microservices, how do you transition the schema db of a particular module without loosing data?
How is atomicity handled in the event driven system. For instance, creating a user should create a wallet but how do we deal with the case where after the user is stored in the db, there is an outage so the wallet isn't created?
At first, you need to make use of the Outbox pattern to ensure the guaranteed delivery of the events (and Inbox to ignore the potential duplicates). If you need more than that, such as some kind of orchestration on top of multiple modules, Saga might be helpful. It's pretty much the same when working with the microservices :) Check out our more advanced project for more building blocks github.com/devmentors/Inflow
@@DevMentorsEN How would you go about implementing the Outbox pattern? Would you use transaction log tailing, polling or something else? This is the biggest smell of EDA for me, relying on transaction log tailing feels kind of hacky but there seems to be no better alternative, at least not one that i'm aware of.
@@khuiification outbox can be tricky indeed - in our sample, in the main solution for Inflow project, we simply commit the events to be published to the DB using the same TX as for our domain models. However, when you think about scaling, this could easily result in sending the same events multiple times - thus you might think either of some smart partitioning, distributed locking (e.g. redis) or other approaches that could handle such cases.
Great content!
One thing to note is that you could make use of that pop filter on microphone :)
Thanks, yes, audio, just like video will get constantly better over time :)
thx you so much 👍👍👍
Cool, Thanks...
Great video. I see however that modules are using same(shared) IoC container. Kamil Grzybek once done modular monolith where each module has it's own IoC container. What do you think about such approach? Pros/cons? Maybe you can extend your modular course with such variant as well?
Yes, you could certainly do it e.g. using Module type built into Autofac container, but in the end, it all boils down to the question, whether you really need it, and what's the benefit? As long as you keep using abstractions, and the implementations within each module are marked as internal types, etc. it's not really a game-changer (IoC module) or so :)
Los encontré justo a tiempo, apenas van en el #2
How is upcoming modular monolith course different from already existing one? I'm asking because I recently bought it, haven't finished it yet.
The upcoming course will be a comprehensive one, about 20 hours long, with a much more sophisticated domain and in-depth topics regarding e.g. event-driven architecture and all its challenges, microservices transition, etc. :)
Thank you for this guys. Would you mind doing a course on event sourcing please.
Thanks, one of our friends is an expert in that topic, but we haven't decided yet if we're going to work on that in the near future.