Hey there, welcome, my name is Mateus Guimarães and we will be seeing each other quite frequently, at least over the next few lessons. On this course we are going to talk about the modular monolith, or if you want to sound fancy a module-oriented architecture, applied to Laravel. A modular monolith is a fantastic middle ground between the simplicity of a regular monolithic architecture and some of the benefits you would find in, say, a microservices-based architecture. In a modular monolith, you decompose your application into smaller chunks, that is, modules. So, you're changing the default application structure.

modules. So, you're changing the default application structure. That makes it much, much easier to reason about the application as a whole because now instead of having one gigantic application, you have an application that is composed of smaller chunks that are obviously much easier to reason about. Having modules also gives you a lot of flexibility. You can extract modules or you can change their behavior and it will not affect the other modules. Now, the term modular monolith might sound a little bit intimidating, but it's way simpler than it sounds.

Now, the term modular monolith might sound a little bit intimidating, but it's way simpler than it sounds. At first, we're going to talk about changing the default directory structure and you might think that creating a module-based application is just really splitting your application into smaller chunks. It is not that simple. Splitting the application into smaller chunks is just a means to an end. What you really want in a module-oriented architecture is ensuring that you have well-defined boundaries within modules and that those modules can work in isolation. Your goal with a modular monolith is to allow teams to work independently on different features,

boundaries within modules and that those modules can work in isolation. Your goal with a modular monolith is to allow teams to work independently on different features, that is, in parallel, and allow those features, those modules, to be independent of each other, to have low coupling. There are two terms that you're going to hear me say quite frequently. The first one is coupling and the second one is boundary. When we're dealing with modules, it is really important to think about how we're going to communicate between those modules, that is, how we're going to cross those boundaries and how much coupling we have between modules. Ideally, we want to have the less coupling as possible since we want those modules to

and how much coupling we have between modules. Ideally, we want to have the less coupling as possible since we want those modules to be independent. But again, everything in programming, there are no silver bullets. Everything comes with trade-offs and it is no different with a modular monolith. There are some trade-offs. We're going to talk about them on this course and I'm going to show you what you get and also what gets taken away when you decide to make those modules independent. This is going to be a very practical course. We're not going to touch a lot of the theory side of things except for this lesson.

This is going to be a very practical course. We're not going to touch a lot of the theory side of things except for this lesson. And what I want you to take from it is to understand how modules work, to understand how to pass messages between modules, and that is the most important thing in my opinion, and allow those modules to be independent. I really hope you enjoyed this series and let's jump into the code. I'll see you on the next lesson.