Nice talk. Take-home point at minute 40 - you can start with a mediator to manage complexity within a monolith, and then migrate to a message bus when you have the need to be more distributed.
Logical != Physical Mediator pattern does not change the fact that the modules are actually calling each other. The coupling is just hidden. Fat events for inter-module communication indicates incorrect boundaries. If the Kitchen needs the Order data, then why are they separate? Why doesn’t the Kitchen own the data it needs to perform its functionality? The repeated error in these talks is the idea that the service boundaries can just be chosen (order,kitchen, etc) when they really need to be discovered based on business capabilities. Hopefully, the wave of faux modularity will soon be coming to an end. The only difference between a truly modular monolith and Microservices should be the physical deployment.
You make some valid points. There will always be some form of coupling, even if it's only sharing contracts; in this case, I think the intent is that the "contracts" are the same as "messages" in the mediator example. Spot-on with the Fat events comment; it's really hard to clearly communicate the appropriate boundaries in such a short amount of time, especially trying to appropriately name things. One thing to consider about your comment about Microservices vs Modular monolith, as you said Logical != Physical. Are these concepts (Modular Monolith and Microservices) actually different? Logically they have the same characteristics. I feel like the terms Monolith and Microservices have complected the orthogonal physical and logical characteristics of these types of systems. As far as deployment goes, we have words for single deployable executables; they are called applications. The term we have for deployments that consist of multiple applications is systems. Sometimes we add the adjective distributed, ie "distributed systems". It would be great if we could separate these concepts again so that we can separately reason about logical decisions and physical deployment decisions. But buzzwords and marketing seem to co-opt every popular idea such that we can't have nice things, only confusion for sales, and clicks.
Fat events indicate incorrect boundaries? Please reconsider your statement. Also check why delta and fat (ecst) events are being used and when. Also consider what ACL and/or ksql (for example) can do.
The suggestion of swapping an in process messaging implementation using mediatr with an out of process broker sounds ideal, however, I'm not sure it would be as straightforward in practice. Some code examples of this would be useful to demonstrate the points in this presentation.
"Logical != Physical" = "If my grandmother had wheels she would be a bike". You make zero sense here. Modular systems are designed to solve people problem not hardware or packaging problem. You want to be able to add changes and work independently on different functionality without creating unwanted side-effects on other parts of the system. As for your kitchen example, visit a restaurant next time. Waiter is mediator communicating with kitchen for you. Waiter tells chef everything he needs to prepare your food. Chef does not need to also process your payments or ask you if you want drinks, does he? "Hopefully, the wave of faux modularity will soon be coming to an end." - There are no non-faux modularity. It's just less or more modular. You should never try to be more modular than needed. Trying to separate into physical deployments is something that only the projects with insanely huge teams should do. You are not Netflix or Google. Most likely abstracting few of your core domains into separate less coupled modules is good enough and you should not dive deeper.
First you waste time taking a photo, then you threatening the audience multiple times (in jest), and then the first slide that that I land on says your images are AI generated. Bounced @ 1m21s. Thumbs up if you beat my improve on my record. I humbly suggest NDC adapt a minimum quality standards for talks.
Nice talk. Take-home point at minute 40 - you can start with a mediator to manage complexity within a monolith, and then migrate to a message bus when you have the need to be more distributed.
Logical != Physical
Mediator pattern does not change the fact that the modules are actually calling each other. The coupling is just hidden.
Fat events for inter-module communication indicates incorrect boundaries. If the Kitchen needs the Order data, then why are they separate? Why doesn’t the Kitchen own the data it needs to perform its functionality?
The repeated error in these talks is the idea that the service boundaries can just be chosen (order,kitchen, etc) when they really need to be discovered based on business capabilities.
Hopefully, the wave of faux modularity will soon be coming to an end.
The only difference between a truly modular monolith and Microservices should be the physical deployment.
You make some valid points. There will always be some form of coupling, even if it's only sharing contracts; in this case, I think the intent is that the "contracts" are the same as "messages" in the mediator example. Spot-on with the Fat events comment; it's really hard to clearly communicate the appropriate boundaries in such a short amount of time, especially trying to appropriately name things. One thing to consider about your comment about Microservices vs Modular monolith, as you said Logical != Physical. Are these concepts (Modular Monolith and Microservices) actually different? Logically they have the same characteristics. I feel like the terms Monolith and Microservices have complected the orthogonal physical and logical characteristics of these types of systems. As far as deployment goes, we have words for single deployable executables; they are called applications. The term we have for deployments that consist of multiple applications is systems. Sometimes we add the adjective distributed, ie "distributed systems". It would be great if we could separate these concepts again so that we can separately reason about logical decisions and physical deployment decisions. But buzzwords and marketing seem to co-opt every popular idea such that we can't have nice things, only confusion for sales, and clicks.
Fat events indicate incorrect boundaries?
Please reconsider your statement.
Also check why delta and fat (ecst) events are being used and when.
Also consider what ACL and/or ksql (for example) can do.
The suggestion of swapping an in process messaging implementation using mediatr with an out of process broker sounds ideal, however, I'm not sure it would be as straightforward in practice.
Some code examples of this would be useful to demonstrate the points in this presentation.
"Logical != Physical" = "If my grandmother had wheels she would be a bike". You make zero sense here. Modular systems are designed to solve people problem not hardware or packaging problem. You want to be able to add changes and work independently on different functionality without creating unwanted side-effects on other parts of the system.
As for your kitchen example, visit a restaurant next time. Waiter is mediator communicating with kitchen for you. Waiter tells chef everything he needs to prepare your food. Chef does not need to also process your payments or ask you if you want drinks, does he?
"Hopefully, the wave of faux modularity will soon be coming to an end." - There are no non-faux modularity. It's just less or more modular. You should never try to be more modular than needed. Trying to separate into physical deployments is something that only the projects with insanely huge teams should do. You are not Netflix or Google. Most likely abstracting few of your core domains into separate less coupled modules is good enough and you should not dive deeper.
First you waste time taking a photo, then you threatening the audience multiple times (in jest), and then the first slide that that I land on says your images are AI generated. Bounced @ 1m21s. Thumbs up if you beat my improve on my record. I humbly suggest NDC adapt a minimum quality standards for talks.
what a bogus talk.