Over Engineered

00:06.90
Chris Morrell
All right? welcome back to another episode of overengineered the podcast where we ask the Question. What's the absolute best way to do things we already have a perfectly acceptable solution for um today I am ah here with matesh Ah Kikamerish. And ah, we are going to talk about modularization. Um, which is something that is near and dear to me, It's not it. It doesn't quite fit into the theme of ah the the absolute best way to do things that we already have a perfectly. Acceptable solution for. But I think it's a great topic to talk about and it's something that you've been focused on a lot lately. A.

00:51.83
Mateus Guimaraes
Yeah, definitely um I feel that in the past six months or so I've been a little bit more vocal about the way that I like to build applications and whatization definitely goes goes into that.

00:59.21
Chris Morrell
Um, yeah, well before we get started. Do you want to just ah, take a quick second to introduce yourself and say hello.

01:08.59
Mateus Guimaraes
Yeah, sure first of all, thank you for having me. It's a huge pleasure to be here. Um my name as a sad is materji myins. It's a little bit hard to pronounce in english so mateass is fine for for all of my english speaking friends. Um. I'm a software developer from Brazil I've been in the larva community for almost nine years now so it's been a while I started with Larville when I was in high school in 2015 so it's it's definitely been a while and um I would say that app.

01:33.30
Chris Morrell
Um, Wow yeah.

01:42.87
Mateus Guimaraes
I produced screen cast and technical content and a kind of thing mostly on Lauraurville but also own some architectural concepts and whatnot. And yeah I think that's pretty much it.

01:53.43
Chris Morrell
Awesome Well um, let me sort of set the stage from from my perspective I think you and I have ah have sort of approached or experienced module modularization in slightly different ways and I think it's going to be interesting to talk about that. But um. On my end you know internetche I've been I've been building software for internetche for over twenty years and it's a you know this application that we've built is ah gigantic and um.

02:21.53
Mateus Guimaraes
Fine.

02:27.48
Chris Morrell
When we first moved to laraval we we you know, followed just the regular conventions but we got to a certain point where just organizing the application um got very difficult and it just felt like we needed some you know, additional layer excuse me of organization. And ah, that's when I set off and and built modular which is our solution to modularization in laravell and the approach that I really took with modular was I I knew that we were veering away from conventions and I wanted to mitigate that as much as possible. So modular is really. Um, trying to recreate all of the larabelle conventions but in a modular way. Um, and we've been using it for a few years now. Um probably 3 or 4 at least at this point our application maybe has 30 different modules in it and um.

03:20.17
Mateus Guimaraes
Her.

03:26.50
Chris Morrell
It's been a really really useful tool for us. Um I think that for me I will say ah you know a lot of applications probably don't need modularization. But I do think that in it kind of feels like there's a a movement in. 2024 to ah, figure out how to get back to like the good sides of co-location of code. Um, and I think even for smaller applications if it makes sense. There are times when you just have a feature That's really well.

03:51.83
Mateus Guimaraes
Yeah.

04:04.23
Chris Morrell
You know, sort of well isolated and and just putting it in its own place can be really useful So that's that's kind of just my take. Um, what got you first started in like thinking about this way of building applications.

04:18.37
Mateus Guimaraes
Um, so I had a company um and we our application grew really large and even though we had a lot of automated tasks and really good coverage and I tried to the the best think send. Ah what I could do back then? um. Write good code that followed the lava conventions it. It got to a point where it was really really hard to make changes um know where things are and I think that's one of the most important things. So um, for example with we but without with event tickets so we sell event tickets. We a platform. So. To to sell events and um I got into modularization where we had to build a fraud prevention system and they started to notice. Okay this This is all the same thing right? This kind of it doesn't make sense to spread all of those different pipeline rules and models.

05:00.98
Chris Morrell
Sure.

05:12.62
Mateus Guimaraes
And some other classes throughout my application because they all relate to fraud prevention and we were having a real hard time keeping up with the application we had I don't know um maybe a hundred models or so and it was just really really, it was just overwhelming to look at that app folder and you know see 30 different directories. Um. 300 files um, I was spending a lot of time trying to make sense of things in my head when I had to do what even though we had really good task coverage and whatnot so say. Okay, so what? if I just create a folder for this called fraud prevention and dos everything in there and um. And this time I'm like yeah, but maybe that's going to against conventions. You know Laville does a lot of magic to know where things are event listeners that kind of thing but I went with it and at the beginning it was very frustrating because I had to start figuring things out myself. Um, register stringing things within service providers. That kind of thing but um at the end it worked out so at that point I don't think I was fully of sewed into modularization I use it for specific modules where I think it made sense to keep things together. Um. And then a couple years later I had an experience with microservices and this was a much bigger team so things were much more complicated. We had several applications. Um, we used different ways to communicate so I was only used to working with monoliths.

06:43.26
Mateus Guimaraes
Um, on this project we use Grpc um, we also had kafka to deliver some events that kind of thing. So after that when I got back into monoliths I started thinking. Okay, what if we could pick the good things about microservices and have them in a monolith.

07:01.63
Chris Morrell
So sure.

07:01.98
Mateus Guimaraes
You know ignore the network calls and the separate Repos stories and the separate deployments all of that have the simplicity of a monolithic application but also have the good things that I like about microservices which are you know, having those independent services allowing teams. To um, evolve differently in different rates different speeds in different modules and whatnot. Um and that's kind of when I started breathing about um modularization in general and started getting into it. Okay.

07:31.91
Chris Morrell
Yeah I mean I think that's a great point like there's been a lot of pushback against microservices and for good reason because I think you know in a lot of ways that was a web development fad. Not to say that there aren't lots of applications that.

07:49.20
Mateus Guimaraes
Yes.

07:51.10
Chris Morrell
Where that pattern makes perfect sense. But I think you know it became ah the the nail that everyone's hammer saw for a while there and um, but there was a reason why so many people got sort of interested in microservice architecture because it does it does. Have some really nice benefits. Um, and so yeah I Definitely agree that you can replicate a lot of the upside of microservices in in application Modules without having as much of the downside. Um, that's a really good point and I think.

08:11.21
Mateus Guimaraes
I.

08:29.34
Chris Morrell
Another thing that you you brought up that um we were talking about earlier is there's kind of 2 different axes that sort of impact your decision to go this direction for us at internetche it was really just.

08:33.16
Mateus Guimaraes
Are.

08:45.68
Chris Morrell
Application size you know we've always always been a really small team. Um, and so the team size didn't really have anything to do with the decision. It was just um, our application is just really really big and it it covers lots of different scopes and it made sense.

09:00.63
Mateus Guimaraes

09:05.00
Chris Morrell
From an organization perspective. But I think um, another important consideration is if you are dealing with really large teams you get into a position where you have to establish more fixed boundaries and. Um, you know there's just a lot of formal processes that are necessary with larger teams that aren't aren't as necessary for smaller teams and so I can see how coming from a you know a place where you were dealing with a lot of those issues give you some perspective on that.

09:40.61
Mateus Guimaraes
Yeah, for sure I do think that the organizational aspect is probably the the one that could affect the the larger grip of people. Um, because the thing is when you add code, you're not just adding code right? You have to maintain it as well. and every time that you introduce coupling and I'm I'm not saying the coupling is bad by any means. But anytime that you introduce coupling you have 1 more thing that you have to pay attention to um, you have 1 more dependency between um, the actors within your software. So I would say that the the organizational aspect is. What I think is the most interesting for small teams. Um, it's just being able to maintain code as your codebase grows larger. Um, it's not just adding more code. It's it's making what you already have more complicated so having at the very least the logical separation between. All the components of your application I do think that makes sense and um, you don't have to go very far right? if you look at the laical core you have different components and this coupling aspect is also taken into account. So for example, um I recently Prd something to. To allow for um events only being dispatched after a database transaction so you have the events module. That's also talking to the database module but coupling taken into account. So if you look at the code there are some some checks to see if we have a transaction manager bound.

11:15.30
Mateus Guimaraes
The container that kind of thing. Um and those are very separated so the work that you do on the event side is very clearly defined and the work that you do on the database side is also very clearly defined. Um of course and that's kind of what I said back then when I started with modularization. Um.

11:17.44
Chris Morrell
Yep.

11:33.98
Mateus Guimaraes
I do feel It's a little bit harder to start with and you spend a little bit more time on the on the foundational side of things. Um, so that was frustrating and I still feel that today. Um, when you're starting a new module or a new project. Even I do take a little bit more time to set up things um compared to what I would do you know. Regularly of application. Um, but I do think that the the logical separation by itself already has a lot of upsides especially as your project grows.

12:04.98
Chris Morrell
Yeah's ah I had never really thought about it but lairvillell is certainly modular in its design and ah and it just made me think like you know I'm guessing that a lot of people have seen somewhere in their stack trace like Foundation service provider. But never really thought about what that is and there's a whole um sort of component of the laravell ah Framework That's whole responsibility is tying all of the different modules together right? like they um. The http stuff talking to the the database stuff you know I can't think of a good example right now. But um, it's ah it's a useful way to think about it and just looking at layer of L code can kind of give you a bit of a sense of how.

12:41.50
Mateus Guimaraes
Up.

12:56.20
Chris Morrell
These separations make sense.

12:57.96
Mateus Guimaraes
Yeah, and if you look at Symphony It's the same thing right? Um Symphony even more so I would say but they they both take into account those those things how big the module is what what?? What does the component into what are the um, the course features he does and what should it delegate to a different module. Um. How those modules communicate to each other is it through a method call is it through events So Lava is a lot of events internally as well. So Um I think those are important things to take into account. Ah, every time that I talk about this someone says okay, but this is overengineering you't. How to think about that. When you're starting out a project. But um I used to think that as well I did not ah my opinion changed a little of it these days. Um I don't think that just because you're starting out of the project. You shouldn't think about how you're going to maintain it. Um I would say that most of us. Most developers are employed by someone right? So you're working for a company. Um, if you're an indie hacker and you're just trying out an idea I would say that's a different that's a completely different thing. You know you're probably working by yourself. Um, you don't have to maybe you don't really have to do it. Deal with your earlier decisions like you do if you're employed and you're working with other people and and the company has has goes and whatnot So I obviously do not think that you should think about everything that could possibly happen within an application in 2 to 3 years and you shouldn't aim for that. But I do think it's important to at least say okay.

14:32.50
Mateus Guimaraes
Um, what is the best way that I can write code that I can maintain in six or six months or 1 year or 2 years and if I happen to add new features to this. How can I write code right now that doesn't take me you know twice as long but also does not grid on me in 1 to 2 years I think that's an important question and and I don't think I have an answer I don't think moduleization is an answer but ah, it's something I try to keep in mind when I'm writing code right.

15:00.63
Chris Morrell
Um, yeah I mean obviously that's like ah a double-edged sword that we all kind of deal with of like when is this a premature optimization and when is this you know thinking towards the future and. You know, oftentimes, there's sort of a middle ground or you know the thing that I think about is you know how hard is this going to be to change in the future and um, you know can I can I do a little bit less now knowing that I might go this direction eventually. But I think that there are certain things that um, you know it's helpful to kind of commit to early. Um and you know a ah good example of that is you know anything that you know may. Eventually be a has many implementing it as ah as many to begin with um is going to save you so much pain in the future. Um, but you know Modules kind of feels like that same thing. It's like if you commit to that architecture from the get-go it might save you some pain in the future.

15:51.87
Mateus Guimaraes
Yeah, yeah, so.

16:09.55
Chris Morrell
Although that said I do think one of the benefits um of of at least the the approach that we have to ah moduleization is we still treat the application module as its own module and that almost becomes like the foundation portion of the app just like in laravell.

16:10.29
Mateus Guimaraes
So.

16:29.25
Chris Morrell
And so you know the the user model is in the application namespace you know in our case like a company model. Um all these like core concepts that need to be passed across all of those different boundaries are going to be used really across the whole application.

16:29.54
Mateus Guimaraes
Ah.

16:47.71
Chris Morrell
We still put that stuff in the application module. Um, and so it's not too hard to introduce the modular package and approach to existing applications because you really can you know they really do work together. Um, but I do think you know thinking about. How is this going to be received by someone in six ten eighteen months is is really useful because you know in my experience we had a new developer join about a year ago and i.

17:08.41
Mateus Guimaraes
Are are.

17:21.62
Chris Morrell
You know I I saw a little bit of the back and forth on Twitter recently Jeffrey way was posting about ah your your course and about um some of the the concepts in there and he got a little pushback that well if everyone follows all the conventions then it's easy to find things and. I I totally get that mindset. Um, but that only works when you know what you're looking for and I think one of the big advantages of breaking things into modules is when you are coming to a codebase for the first time or coming back to a feature that you haven't touched in. Twelve months um you have 1 place to just scan through and look at the whole feature implementation. Okay, so this has these models. It has these controllers. It's using. You know it's using actions in this or it's using verbs or you know, whatever. Ah.

18:03.22
Mateus Guimaraes
Are.

18:20.25
Chris Morrell
Feature that that particular or whatever approaches that particular feature need you can kind of get a whole overview whereas if you have you know the the 3 controllers in your app controllers Directory maybe under some namespace and then you have the model in your models. Directory. And you have the form request in your http request Directory You know when all those files are spread across your whole application. It becomes a lot harder to get the the full shape you know and I think that that goes to what you were saying of what.

18:49.76
Mateus Guimaraes
A.

18:57.20
Chris Morrell
What's this going to be like in 6 to twelve months um it's easier to come back to or to to approach for the first time I think when it's when everything's a little bit more co-located.

19:07.94
Mateus Guimaraes
um no I definitely agree and um I think people tend to be a little bit more um, more radical on their opinions online. So sometimes when they say okay I like modules they think oh so you think the default structure. It's bad. And I don't think that by any means I think the default structure is perfectly fine I just feel that for the applications that I've built in the the last five years or so going modular is just better. It's not that the default one's bad. It's just that I think modularization is better especially in the in the long term. Um. So so having things collocated especially when you're onboarding someone new makes things so so much easier. Um, we have I'm working on a project where we're migrating from a legacy codebas to a new monolith and I've seen this just now we have a payment processing module. So everything related to payment processing is there. We have different gateways we have face for different types of things we have different actions models keeping codes a lot of things and they're all in there. So if someone were to join this codebase and say okay, we need to make a change to how we take payments. They don't have to scan the entire codebase they know where it is.

20:08.52
Chris Morrell
Sure.

20:19.66
Mateus Guimaraes
It's everything in 1 folder. Um, so I definitely think that that aspect is for most projects. 1 of the most important ones and um, because as you go down the rapid hall you can start talking about coupling between modules and how you're communicating between modules. Um. A 3 d method call is it through an event. Um, do we have eventual consistency that kind of thing between different modules which I think is still ah, an interesting conversation especially is your project where it's larger and whatnot. But I don't think it's essential. Um, for most projects. And on the lacasts course. 1 1 thing that I tried to do is I win a bit overcoll on a lot of things. So it's an example project. It's simple but I went very overco in some things to showcase how that could help you somehow. So. At the end of the course we we try an event-driven approach where we dispatch events to talk between modules I obviously wouldn't do that in an application of that size in real life. But the application that you're working on is not that small. It's a big one and that starts to make sense. Um.

21:23.83
Chris Morrell
Sure.

21:31.81
Mateus Guimaraes
So 1 thing that I tried to and I'm not sure if I succeeded on that was from the beginning say everything that you see here is you know artificial. It is overcoll and every time that I talk about couple. It is a spectrum. It's not It's either. You know loosely coupleled or tightly coupled it's in spectrum. It really depends on what module you're talking about how much autonomy you want to have on a given module those kinds of things. It's it's not 0 or 1 um, like a lot of folks think it is and.

22:02.14
Chris Morrell
yeah yeah I mean and that's that's definitely um, something that we we try to keep in mind at least ah internally is ah you know you don't have to be dogmatic about this stuff and ah. You can just use these tools as useful. You know how they are useful to you so you know in our case, we don't really worry too much about Um, you know the coupling modules or really the the boundaries between the modules don't matter too much. To us because of the way our team works because of the way our application works um those tradeoffs just don't make sense for for our use case and you know we can make that decision and in another application. It may be really important to keep the the boundaries between modules really really firm and. You know that app the the developers of that application can make that decision but I really think that a lot of the conversation about these architectural concepts and um, you know when you get into domain-oriented design like. It comes with a lot of baggage because unfortunately I think that a lot of people who are advocates of um, some of these approaches can you know, get really really fixed on well this is the only way to do it and there's only 1 right way to do it and you have to do it this way.

23:32.66
Chris Morrell
And it kind of hurts the whole you know the the whole ecosystem because there's never just one way to do something and it always depends right.

23:42.25
Mateus Guimaraes
Yeah I mean you mentioned a good point. Um, you know I have a lot of friends who are into the did d um I wouldn't call myself a a domain driven development guy by any means. But I've I've read some things. Um. 1 thing that I really do not like is the terminology. It sounds really complicated. So when you see someone talking about domains and subcontext and aggregates and aggregated roots and value objects and that kind of thing it sounds really really fancy and when it started learning these things.

24:01.37
Chris Morrell
Um, yes.

24:15.29
Mateus Guimaraes
Was very intimidated because you see those evangelists or whatever you want to call them saying that this is the right way and you have to do things this way in a bunch of complicated terms and I thought that what I thought that it was really really complicated and it turns out it wasn't so complicated. Um.

24:34.39
Mateus Guimaraes
I Definitely think that there's a lot of useful knowledge there. But I agree with you Um, people do feel like I feel like people do insist. There is a bright way to do things and everyone else is wrong. Um, but. And I know this kind of unrelated to to Domain-d drivenven design but I I Also think that people focus on the wrong pieces of domain-driven design. Um, they focus on the tactical patterns. Um, instead of focusing on. You know, domain knowledge and how to ensure that you can moderate. How how to ensure that you're modeling your domain properly that kind of thing. Um and I feel some confusion comes from that I would say that people like to focus on the least important piece of the did D which is you know which director you're going to create are you going to create a valid object. Do you have an aggregate I don't think that's us important.

25:17.66
Chris Morrell
Sure.

25:26.75
Mateus Guimaraes
As the other pieces as a strategical piece of of the main-driven design and I also feel that kind of goes together remoization because when you createor Modules Even if you do not let's say that you're just creating modules and you don't really care about boundaries and coling and whatnot just by the fact that you have a module and you have a place. Group Files you kind of already do care about that. Um, you're keeping things that are related to gather So you're you're by default already creating a cohesive application. Even if you don't think about that and um, that's one of the things that I like about modularization. Um in my experience and. Maybe other people did not have the same experience. Um, it really really I was going to say force you but that's not the right word but it really pushes you to start thinking about um you know cohesiveness and which things should live together in your application. And that kind of thing and I I felt that for me that really made me it made me think about applications in a simpler way than I would if I had a huge application where everything is you know, scrambled through the application. I'm a sure if that makes a lot of sense. It does in my head but it maybe doesn't know that I'm saying.

26:45.19
Chris Morrell
Um, no, no that that's I that makes a lot of sense and I I think um, you know I think you're right that just forcing the question of where does this belong you know, kind of encourages you to think about. A few a few steps back. You know? and um, yeah I think you're you know I I said before we don't really care too much about the boundaries between Modules but obviously just having Modules is establishing boundaries and there are certain ones that you know we're a little bit more.

27:12.99
Mateus Guimaraes
Perfect.

27:21.19
Chris Morrell
Um, yeah, we're a little bit more careful about either. You know there are a couple of features that we've built as modules and then eventually extract it out into their own packages to open source and so if it's something like that I'm going to worry a lot more about the boundaries then um than elsewhere. Um, but yeah I mean you know I don't know how much we can't we talked a little bit off air. But I can't remember how much we talked about verbs um verbs is ah an event sourcing package that Danielle Colbert and I have been working on for a while and. You know it's really a direct sort of reaction to some of the stuff that you were just talking about all of these concepts and event sourcing the the aggregate route and projection and you know command query as segregation responsibility like all all these different. Ah.

28:16.41
Mateus Guimaraes
I.

28:17.55
Chris Morrell
Concepts can make an approach to designing an application that has value really intimidating and um when you get really strict about the way you approach something like event sourcing or ddd. Um.

28:37.73
Chris Morrell
That that that rigidity ah can be really off-putting and so when we sat down to build verbs. The idea was how can we encourage the best of the best practices. Ah but also sort of pull away all of that. Boilerplate that just felt so bad. Um, and and I think some of that same instinct. Ah that that came from or that that inspired verbs um is you know it feels like it's in the same vicinity as what. Appeals to be appeals to me about modularization because you know so we've we've been running um our exam system. Ah we we migrated our portion of our exam system to a ah new event source system and that's been running in production for years now and. Ah, it's been great, but the 1 thing that's constantly been a frustration for me is you know every time you add a new thing. A new event. To go into your aggreate route and add a couple functions you have to go in. You have to create the event you have to go into your projector add a new function you have to go into your reactor and add a new function. You have to you know, just have to just for 1 little thing you have to go into 6 different places and create files or add new new methods. Um, and.

30:06.29
Chris Morrell
Sometimes even though we're still doing that. Um, in modular. You know we're still creating a form request and ah a controller and a model and a policy in a um factory right? Maybe we're still creating a bunch of files. But at least. All the those files kind of live together and are in 1 place you know whether they live together in one file or live together in one module it kind of feels like the same that same general sensibility of just like all the stuff. Ah, or. Yeah, pull away some of that like complication and just make it simpler to figure out. Um I feel like I had a point that I was I was heading towards there and then I got sidetracked. But um, so.

30:58.56
Mateus Guimaraes
No I think it's easier I think I think a point you can take from that is that collocation is usually good right? At Least that's been my experience and and if you think outside of the web a little bit. Um, ah I think with Embassy Frameworks and that kind of thing that. We forced? Um, a natural separation of things by type grouping by type so you have models altogether you have controllers altogether. But if if you look at other types of Software. That's not I don't think that's as dominant as it is within web development. Um, if I didn't know anything.

31:32.75
Chris Morrell
Um, yeah I honestly I honestly think that the ah Psr standards for file. Ah for class loading. You know they they overall. Did a huge you know all the Psr standards have been tremendous and composers just been amazing for the ph p ecosystem. So like I want to say that first. But I think this one file per class approach. Um you know has really hurt ah hurt the ph p. Ecosystem a little bit because there's just times when it would be so much. It would just be so much better in in every way to just drop your you know your form request object in the same file as your controller right? if the controller. If this controller is the only class that ever is going to deal with this form request like why do they have to be 2 separate files and 2 separate namespaces I think that's one of the reasons why a bunch of people. Um, get frustrated with some of these patterns is just. Sheer volume of boilerplate that you have to create when you want to add something simple and a lot of that I don't think would feel nearly as bad if it was just oh I'm just going to add a second class to this violin call it a day. You know.

32:57.13
Mateus Guimaraes
Yeah man I agree. Um I Recently not recently a couple months back I tweet something so I do use value objects frequently and sometimes I have value objects that are aching to an aggregate it only works within that context and I hate that I have to create a new file to use that.

33:11.97
Chris Morrell
Yes.

33:14.81
Mateus Guimaraes
In a single class I will love if I could jets drop that in the same file because even to make my life easier I don't have to jump between wishboll files I know that it you know it's related to the parent file it is on the same file I'm sorry to the parent class. It is on the same file I don't have to look in a bunch of places. Um. We we spoke briefly about that offline I do think that when when you create those patterns and you know those sorts of things you do have to establish guardrails because you you don't know who's going to be using it and um I imagine that the psr folks thought a lot about that. Um, so I don't have the context they have when they. When they set up those rules I personally would love to be able to have 2 classes in a single file or multiple classes in a single file but the the guardrails aspect is something that stuck to me ever since I worked in a larger team. Um, like if you have a. Ah, number of people were even worse in the case of psr you didn't know who those people are um, it's really hard to say be pragmatic because you know I might do 1 thing. You might do something fatal bit different. So I think we spoke about this when we were offline on on this larger team. Ah, where we did microservices.

34:17.95
Chris Morrell
Um, yeah for sure.

34:28.81
Mateus Guimaraes
There were a lot of practices that went a join I thought were you know I thought it was spoilerplate and like you know why do we have to do this but sometime later I realized why we had to do this because everyone who didn't do that broke things. Um, you know if you have 6 people working on on on an application.

34:39.88
Chris Morrell
So.

34:46.80
Mateus Guimaraes
It gets really really hard to make sure that everyone's on the same page and that you're following the same conventions throughout the application. Um, so conventions in some thing are considered important people always think I'll always talk about the different La about structure and um I can't recall who it was but someone asked me what do you think about having. Regular layer of application but also have any modules and like you know, ah I don't think that's a great idea I think you have to to pick something if your convention is the default convention then it is a different convention if it is Modules then it is Modules I Think if you mix a bunch of things. They kind of lose their purpose because now you have a mixture of modules with a regular layer of application and you still don't know where to look for things because it could be in a module. It could be in the common directory the common type directory. Um, and so I think for teams the the most important thing is speaking on what. Everyone feels comfortable with right? Ah, rather than trying to use the latest the the latest thing or the the cool thing or the the hyped thing. Um which I do see happen a lot I don't know about you but I see that very frequently.

35:57.53
Chris Morrell
Yeah, um, no I mean I definitely agree and and I mean that's the reason why even though I I wish I could do it a different way I don't right because.

36:13.36
Chris Morrell
In the end following known conventions. It just saves everyone so many headaches and and for the most part your tooling should be able to help with a lot of that. Um, we've definitely invested in a lot of of internal tooling and and open source some stuff to help. Ah. Mitigate it because it's I think the ah when you are talking about conventions and pull requests that feels bad right? You shouldn't the code review should be about the code not about the the code style I think the tooling should should for the most part ah solve that. Um, but it's important and and definitely as ah, you know as either your your application grows or your team grows or you know if you're working on open source and and you want to um, get contributions that are. That are useful from other people like these things start to matter a little bit more um and we do. We do have to trade. Um, we it's a tradeoff right? Sometimes. Ah, there is a way that probably would feel a little bit better to you. That's not Conventional. Um. And so it's it's more stepping back and and thinking about the bigger picture and and I think that you know to your point. That's that's why the Psr standard is the way that it is is they had to pick something and that felt like the best um the best standard to use because.

37:48.85
Chris Morrell
It's a lot easier to say one class per file than it is to say one class per file unless you have a good reason to put two classes in your file you know like so you know I I can live with it. It's just a a little little frustration of mine.

37:56.91
Mateus Guimaraes
Yeah, yeah, a hundred percent

38:08.56
Chris Morrell
And I think I think that um in the end thinking about Modules helps me kind of mitigate that because even though I'm still dealing with you know, maybe creating 3 or 4 or 5 different classes when I'm introducing a new um, a new model. For example. Um, it doesn't hurt so much when I know they're all going into into a you know? Nice focused place.

38:35.80
Mateus Guimaraes
Um, yeah man. Um I feel like that's that's something that Modules bring that people don't really think about ah the Blast Radius If something goes wrong is much smaller. The the surface area of everything really is much much smaller and.

38:45.98
Chris Morrell
Yeah.

38:53.79
Mateus Guimaraes
This is the kind of aspect that I have a hard time to explaining um simply because I don't know how to put that in words I think it's a kind of thing that you have to you have to suffer from the first then see the other way and then go you know that actually makes sense. Um I stay there with Modules just because you have things colocated.

39:03.50
Chris Morrell
Yeah, yeah.

39:13.73
Mateus Guimaraes
Um, if you mess something up, You're not massing your entire Application. You're massing that specific module. Um, so these days Um, someone asked me from from the La Ss Horse and read a zm and they had an example of. Well what if you have a blog application would you still you know modularize that isn't that overcall and my answer was you know, just create a blog module or a blogging module. Um, there is a sorry I'm I'm kind of deviating from subjects here but that just came to mind and I think it's interesting.

39:50.81
Chris Morrell
No go for it.

39:52.60
Mateus Guimaraes
Um, uber has an article called domain orientiented micro microservices. Um, which people call macroservices so they pretty much describe instead of going very micro. You know, extremely micro. They just start to building one microservice per domain domain. So you. You know if blogging is a domain make that a module. Um, it doesn't have at least I don't think a module has to be extremely small like only a couple files I think a module can describe an entire domain and then you can have sub modules. So that's something I do a lot. Um, we have for example.

40:29.77
Mateus Guimaraes
Have the shopping module which relates to everything related to buying product. So inside this shopping module. You also have a checkout context which has everything related to the actual checkout which you also have the card. You also have the ability to save your card. You have the ability to add things to your cart that kind of thing. Um. And and and that's um, that's 1 thing that ah I I do not see a lot of people talk about the module sizes. Um, when it started braing about this since I had this microservices context my initial thought was always you know. Let me try and make this module as small as possible and after reading this from uber and shopify also has 3 rate articles on on modularization if I'm not mistaken github already also has one and they all describe those bigger modules that encompass an entire domain. So they're not confo for example with only 1 aggregate routed on that kind of thing they're much bigger. They just describe a behavior the the or um, an allowance. The user has on your application. Um, so what's something you can do in this application you can shop so you have a shopping module. Um, you can check out an item so you have a checkout submodule or even a complete separate module. Um, you can register. So maybe you have an authentication module that kind of thing and and and that's how I started thinking about applications. You know, um, what what is the the core concept.

42:02.70
Mateus Guimaraes
That the thing I'm building falls in you know, Um, if I'm working on a payment model. What is the core concept of that is that a payments thing or is it strictly related to an order for example, um, and and that's why.

42:18.20
Mateus Guimaraes
Um, especially with the course now that people are watching it and they're they're asking me questions I have a hard time asking some of them because they go and say okay so if you have a payment model and you have an order model and you have you know?? Ah, whatever which Modules do I create and like I don't know because I don't know what your software does right? yeah. It needs to make sense to your software to to what your business does. Um, and that's where I think going back to what we discussed earlier about you know, being dogmatic. That's where think being dogmatic just doesn't work because the answers are always going to change. They're always going to vary.

42:56.23
Chris Morrell
Yeah I mean that was the other thing that kind of struck me about the um, the the sort of Twitter back and forth earlier was you know it's just like.

43:11.67
Chris Morrell
We are smart people making hard decisions all the time. That's that's basically what our job is is to figure out how to solve problems and do that in a way that is you know, effective and efficient and and easy to maintain and you know secure and. Fast and all all the different things right? And like if you if you really think about it. Someone who says you know well I have this order model and this cart model and this you know shopper model or whatever and they're they're asking you where to. Where to put each one Well you could basically ask Well Why do you have an order model and a cart model and a shopper model right? like you had to make a call um about what are the things that are in your application and what you're going to name them and you know sort of thinking about. Ah, Modules is the same you just you just have to make a call and you're going to get it wrong sometimes and there are plenty of times when yeah, maybe it you know a good example that I can think of is you know we have an exams module and we have a certificates module and you know you. Receive a certificate upon completion of an exam and like there are things that I could argue it goes in the exams Module or I could argue it goes in the certificates module and either either is either the right choice or both of them are wrong. Choice. You know you could think about it Either way.

44:36.60
Mateus Guimaraes
Her.

44:47.95
Chris Morrell
Um, but like we just had to make the call and that's true of everything like you just you have to make calls all the time in programming about how to approach a problem and there are usually dozens of perfectly acceptable answers and you just have to pick one and it's more.

44:50.10
Mateus Guimaraes
Yeah.

45:07.88
Chris Morrell
You know following the same heuristics for your team every time right? having your own conventions having understanding within your team about well for this type of thing we collectively have decided to do this right? and ah, that's not to say that it's not important to have. Conventions and rules. But those only get you so far right? at a certain point. It's just like it just depends and you just you pick a place and hopefully if you get it wrong. It's not too hard to refactor later and. It'll probably be Fine. You know.

45:45.29
Mateus Guimaraes
Yeah I think there was a big mindset shift for me which was just accepting that I am going to get things wrong. But when I'm writing something I'm also thinking. Okay, if I happen to get this wrong. can I can I write this in in such you can can I architect this in such a way that if I happen to get this wrong. It's not so hard to anddo it or to change it um earlier in the conversation. You mentioned they has many thing um and and and that's 1 thing that I think if you haven't been bitten by it. You don't know about it. You know so. It's one of those things it needs to happen first. So you have the knowledge and say okay maybe this should be a hesman relationship because I've been bitten by this in the past and I already know about that and um.

46:31.81
Chris Morrell
Um, yeah, yeah, that is I mean you know that's that's the unfortunate truth of a lot of this stuff is just like you know you have to learn your own lessons and you know I I can't. I can't say the number of times that someone said well why did you do this and my answer is well in 2001, you know or like well we had this vendor five years ago you know like it's just it usually it's just you you have to. Yeah, have to have some of that pain to to know to avoid it in the future.

47:15.38
Mateus Guimaraes
Yeah, but I mean um, you're going a little bit outside of modularization. Um I do think it's very important to to explore things right? explore ideas and explore solutions explore patterns. So um, I'm I'm going to mention the course again just because now that people are watching it. They're making questions. Um, some guy asked from warcast ah, how do I know if I should use this and and I don't have an answer the the answer is you know create a new branch. Try it out. See what you think see if it makes sense share with your colleagues see what they think um maybe doesn't but if it doesn't at least now you know that. That's not a solution for the problem that you have. But maybe you can apply it to other problems and I think it's the same with domain-driven design with event sourcing withqr as we keep hearing all of those Bestzzwords and I would even go as far as saying that the moular monolith is now a ubi word people are repeating that nonstop. So with hearing those things and I'm saying this because it happened to me I kept listening about d to d securer ass kling architecture you know ports and adapters and I didn't know what they were so until I snaped my toe into the water and play with it a little bit I started to get a glance. Okay, this kind of makes sense to me. I don't really see benefit on this? Um, but I think everything related to to architecture and and modularization is architecture um is one of the things that that the the answer actually is depends it's it's not a meme it's it actually is depends you you know what the software does.

48:47.35
Mateus Guimaraes
You don't know what problem they're solving you don't know their context. Um, you know even ecommerce applications are vastly different. You. You don't have recipes you have ecommerce applications that that are ominy channel they they also sell physically and they use the same software. They also have partners ah selling stuff. They ship for other people that kind of thing. So um I would say that one of the things that I learned the most with with modularization really is how to think about the domains of my application right? What does my what does business do really. Because at least what I tried to do and and I think you kind of feel the same is I try to make the modules match the different aspects of the business right? So in your case, you have an exemps module because you have people taking exemps. Ah you have a certificates module because you give people certificates. Um and. To me. It was very much trial and error. Um, many times I created modules that you know one month later I was like okay that makes absolutely no sense. But since it is a module and since everything in it is somewhat self-contained and complicated. Making that change is not as hard as it was. You know if I had that in ar regular application tango between the webs of different classes and a bunch of other things. So um I do think that that nowadays um, building module applications.

50:20.98
Mateus Guimaraes
It It makes my life easier in the long term even in the short term. You know so.

50:27.99
Chris Morrell
Yeah that's ah, that's definitely something that we've done. Um and I haven't really thought about it as ah and as an advantage. But yeah, like because your modules are you know in their own namespace and you know we have tools that. Make it make refactoring pretty easy nowadays. Um deciding to back out of a module is a lot easier than deciding to modularize after the fact right? because I can just take you know my modules exams all my that whole namespace just move it right. Into another module or rename it or you know if I need to expand the scope of the module I can rename it pretty easily if I need to you know combine 2 modules as long as there aren't naming conflicts. You know within the actual classes. It's relatively easy. Um, or you know.

51:15.80
Mateus Guimaraes
And.

51:23.24
Chris Morrell
Move something into sort of a Sub-module. There's There's lots of um, there are lots of opportunities to change your mind. Um, and you know there have been features where I just had an idea over the weekend and I wanted to like stub it out. Start a new module and I can just throw the whole thing away obviously with version control. That's not a big big advantage. But I think it's almost like a mental advantage of just like oh this this entire directory I Just need to to walk away from it. You know it just trashed the whole thing.

52:00.71
Mateus Guimaraes
Yeah, yeah, you know one thing I do is sometimes I'm working on a module and I'm not really sure if that's going to work out what I do is I look at the pull request tiff and since the module is a different directory I know at first glances if I touched anything unrelated to that you know so um. I know which other modules I touched I know which other models I touched that kind of thing whereas if you have everything together. It's it's just it's really hard to visualize what you're doing amongst a sea of other unrelated things. Um, and I do think a huge advantage is.

52:34.61
Chris Morrell
Um, that's a really good point. Yeah I mean that definitely okay, sorry good. Um, yeah, um, well I was just going to say that I I have observed that benefit a thousand times.

52:39.32
Mateus Guimaraes
Yeah I think a huge advantage and just are you go ahead. Go ahead, Go ahead.

52:53.75
Chris Morrell
But I never really um, articulated it and when reviewing a Pr. It's so much easier to to understand the scope of the change. You know, especially if the feature if the change is really. Isolated to a specific feature. It's it's so much easier to say. Okay, yeah, this is only changing files within that module. So the the scope of like unintended consequences I already know is smaller. Um, it's already easier for me to know that the.

53:25.65
Mateus Guimaraes

53:32.64
Chris Morrell
You know the implementation meets the the feature requirements because I I can see that it's not like reaching into a bunch of different places. Um, and that has been super valuable for us. Um, because it definitely makes it easier to review. Code changes and and even just understand a Pr even if it's not just a review but I need to understand how this pr works I can look at what modules it touches and quickly see the scope in a way that if I was just seeing a bunch of files across the entire application. Just take a little bit longer to figure out what's going on.

54:13.40
Mateus Guimaraes
Yeah, for sure I mean I think that the fact I think maybe you feel that with event sourcing as well. The fact that you cannot just cowboy code and you know run a few commands and create a model a controller I probably see a listener all of that real quick and you have to stop for a while and think. And think on things. Um, obviously this is not related to moularization or even sourcing or anything but it it kind of forces you to do that? Um, when I'm working on a module or anything anything like that or createing new one I have to stop for a while and think okay, what what ah what do I want to do with this what problem and I trying to solve with this. Um, and obviously um I think you can you can? Um, you can definitely do this outside of the scope working on any application but it's something that I dating used to do on on I'm going to call them regular la of applications because I can just type a command real quick and get moving. Um. So that's definitely something that benefited me and I think another question that's important to make we we always make the question. Why should you deviate from the default structure. But I think an important question is why is the default structure better. You know why is grouping by type. Better than not grouping by type and I don't even know the answer for this I don't know when people decided to start grouping things by type. But ah it goes back to context maybe for you for your application. It does make sense group by type I would say that for the applications that I work on today. It usually doesn't.

55:32.31
Chris Morrell
Sure.

55:50.66
Mateus Guimaraes
Usually makes more sense to group by feature group by module.

55:55.00
Chris Morrell
Yeah, no I agree entirely with that I mean I think um, you know if there is 1 thing that I could wave a magic wand and change about laravell. It would be um, rethinking that that application structure. Although you know. I wish that I had looked into this a little bit more because I don't I don't have the conclusion to this question but are they the the reasoning behind it. But I was talking with Taylor about this a little while ago and he mentioned that symphony. I think in the switch between version 3 and version 4 um actually backed out of a more modular approach to application design. So in version 3 of symphony um, your application was built in what was called bundles and each bundle is like its own module and. I could be wrong about the the the specifics because I haven't really built um symphony applications outside of the lareville context. But um, you know there was a a real decision within that um framework to sort of. Step away from a more ah ah, modular approach and I'm I'm curious why they made that call because I yeah personally I would love to see sort of us heading more in that direction not away from that I'd I'd much rather see things grouped by feature.

57:27.54
Mateus Guimaraes
Um, yeah I thought about that for a while I don't know if for the gender audience I mean for most people it makes sense to to have that default. But I think just you know asking the question. Why is the status quo better I think it's important question that sometimes we do not ask and. I'm saying this about myself. Um, every time that I jump on a new framework or I I grab a package or anything like that I very hardly question. Myself. Why is this the best way is it even the best way I don't know you know, um, the same thing with with even modularization when I first. Sort of learning about it I didn't question myself. Why is this better than going the stricture now I have the answers now I know why I think that's better. Um, but back then it didn't and um I think it's important to have community-d driven aspects and have default structures I think that's that's It's really good, especially for beginners. But I think that for those of us who who are already in the industry for a while. It's really important to to question ourselves is is this option. First of all why is it the default and second of all is it really better. For the solution. We're looking for or is it simply the default you know, um and that's kind of the conclusion I reached with with modular applications at least for the kind of work that I do.

58:52.99
Mateus Guimaraes
Obviously if I were writing a simple blog or a simple application I probably would just go with the default structure and do things quick and get it to market real quick. But for the kind of applications that I do that I'm working with other people. Ah that the business usually has a clear go I found that grouping things by Module makes much more sense.

59:00.20
Chris Morrell
Sure.

59:12.33
Mateus Guimaraes
Then grouping things by Thai because you know, um what does a blog post have to do with an order or a product even though they might live in the same codebas and they might live in the same directory and they might be next to each other. Um, the only thing they share is that they are models. But that's it.

59:31.49
Chris Morrell
Yeah.

59:32.14
Mateus Guimaraes
It ends there. Um, so by experience and by you know, trying new things and trying new approaches. So you know we're we're mostly talking about these strategical piece of modularization and not talking so much about code. But even on the code side of things I tried a lot of things I tried you know. Going with a default structure I tried going with those ah domaindriven design inspired versions where you split things by domain and application infrastructure I tried vertical slices. Um I had to try a bunch of things to first find something that I enjoyed. And later share that with my colleagues to see if it makes sense for them as well because just making sense to me isn't enough I work in a team so it needs to be something that everyone's comfortable with.

01:00:21.78
Chris Morrell
Um, yeah I mean and and that's that's the um, unhelpful answer to the to a lot of this stuff is like you just have to figure it out and choose what works best for you right? like it's not there. There just isn't. A perfect recipe for everything unfortunately.

01:00:40.11
Mateus Guimaraes
So yeah I do think it is it depends but I also I don't think it's just it depends or I don't think it's just whatever I think it's it depends. But there's definitely 1 thing that you're going to think is fast and that's it one you should pick you know I think you should stand by. Your opinions I see this happen a lot of time people think something think something is bad but ah, you know they don't do it or they do it differently because someone else said so um and if there was if there was 1 thing I've learned um in this almost ten years that I've been developing is you know. People don't really know what you're working on. Um and even when you you grab some really smart folks I'm definitely not 1 of them. But you'll listen to some really smart folks and they have general advice. Um, it's easy to think. Okay, they're probably right and I'm wrong because they have you know 30 years of experience and they've worked. At this place this place and this place but it's also quite possible that for your context they're wrong I feel that if you're if you're doing things and you're following patterns and that kind of thing and you sure they do not make sense if you feel they're super complicated and you don't like creating a bunch of files. And you think it's slowing you down. You're making things more complicated. It probably is making things more complicated and you probably shouldn't send by it. You probably change things you know.

01:02:02.42
Chris Morrell
Yeah I mean I think my hesitation there is um that a lot of times a lot of times. It isn't so easy to know and and also a lot of times.

01:02:03.99
Mateus Guimaraes
So.

01:02:14.16
Mateus Guimaraes
Yeah, definitely.

01:02:20.46
Chris Morrell
Ah, even if you can come up even if you have a really solid argument for why? Um, some different approach is better than the conventional approach I think that um, sticking to the conventions often is.

01:02:37.30
Mateus Guimaraes
But.

01:02:39.16
Chris Morrell
Just so much easier for other people in the long run that I do think you have to have a really good reason. Not to say that you shouldn't that you shouldn't explore and and and certainly um, you know consider.

01:02:42.23
Mateus Guimaraes
Yeah.

01:02:55.47
Chris Morrell
Ah, ah, consider different options because there are lots of times when there is a better approach and it makes sense for you. But I I just I'm I'm a little bit a little bit ah hesitant to to fully say like yeah, always question the conventions because a lot of times. It's just like no if the convention is. Is fine Even if you think there's something a little bit better like stick with the convention because it's just going to be easier for everybody in the long run. Um and really decide when to choose those battles because um, they're going to introduce. It's not just that they introduce a little bit of friction now but they essentially introduce friction forever right? like moving forward. So.

01:03:40.20
Mateus Guimaraes
You know? Yeah definitely I should have worthed the battery. Maybe what I wanted to say is you know question the conventions even knowing that you're probably wrong and they're right because if task it is with a bunch of people and through a lot of time. But um, my point is mostly. You know sometimes you are right? Sometimes what you think is sebas is vast and I see that happen I see that going both ways, especially with for example, domaind drivenve design I see these people trying domaind driven design and you go you know I don't like this this doesn't make sense to me and it probably doesn't um. You know someone someone who's super experienced and highly renoed on their failed. It doesn't mean they're always right Um, and going back to to modularization real quick if you have a modular application and you're still following the Laura about directory conventions is that not.

01:04:20.50
Chris Morrell
Sure.

01:04:32.55
Mateus Guimaraes
Do you think that's following the conventions or.

01:04:35.20
Chris Morrell
Um, well I mean that was why we I mean that was really why we built modular is we wanted to kind of have the best of both worlds. Um, and you know that there's there's the ah, really popular Larall modules.

01:04:44.47
Mateus Guimaraes
Here.

01:04:51.68
Mateus Guimaraes
Are.

01:04:53.98
Chris Morrell
Package. Um, and the thing that kind of put me off of it was just there were a lot of decisions that felt like things were just a little bit different. Just for the just because they were a little different not for any really? um, noteworthy reason right? like um, just just little things like um where you put your views or where you put your um where you put your? ah.

01:05:16.00
Mateus Guimaraes
Um.

01:05:26.76
Chris Morrell
Factories I can't remember exactly what it was but it was just like oh and if we're using this we have to put our views in like a capital V Views namespace in a different directory or something you know something like that and um, that just felt like.

01:05:46.66
Chris Morrell
Why is this different? Um, and so I think yeah you you can I think continue to follow the laraville conventions ah with a modular approach and I and I haven't watched ah too much of your.

01:05:47.10
Mateus Guimaraes
Yeah, which is a good question.

01:06:03.82
Chris Morrell
Ah, laircast series yet. So I can't speak to it much. But I I get the sense looking at it that that's basically what you're advocating for is you're still kind of following the same conventions just inside of separate namespaces right? essentially.

01:06:17.44
Mateus Guimaraes
Yeah I mean on the course I kind of show different options. Um I would say that personally what I Really like these days is are vertical slices. So I just create a folder that describes a feature and I I dump everything in there. Um.

01:06:20.70
Chris Morrell
Okay.

01:06:32.45
Mateus Guimaraes
But in that scene like you said ah previously. It's not necessarily what I think is best right? So for example in the project that I'm working on right now. What we do is pretty much modules and then layer of open dimensions pretty much modular. Really? um, you know, ah the source folder being the equivalent of the app folder and then.

01:06:49.81
Chris Morrell
Yep.

01:06:50.68
Mateus Guimaraes
Database Dev and resources views. The kind of thing on the root of the module and I agree I mean and personally I I I Really like vertical slices I think it makes a lot of sense but I do think that having something like modular. Um the structure that it provides the default layer of structure within Modules. It's a really really interesting middle ground between still following the Larville conventions but also having the necessary context to make the changes on your application.

01:07:23.40
Chris Morrell
Yeah, it felt like the right balance. Um, and you know a couple of years out I still I still feel like that I because I I definitely um I appreciate the appeal of you know, introducing a new namespace and just kind of throwing everything in there and not having. So and like sort of peeling back a little bit of the structure like I think there's there are um, benefits to that. But ah in the end you know and and we like I said we kind of tested this theory and it feels like it's played out you know, bringing on a new. Experienced laravel developer who's never seen module or before um you know he was really able to very quickly get comfortable with adding new features adding new modules modifying ah features you know because it's really just 1 new concept to learn. Right? Everything everything else is exactly the same um and that feels that feels good to me and I think like even if you weren't using modular you could you could essentially do that that same approach. Um, and I think I would encourage it as sort of like a starting point. Um. As like a comfortable middle ground.

01:08:38.10
Mateus Guimaraes
No I think it's fantastic, especially because if you use modular you get this scaffolding commencse back right? which is something that people usually miss As soon as you go out of the lar of way like okay how do I create a motto. How let's create this by hand and like these days I do it by hand because I'm so used to it. But having the commands available is a huge time saver for.

01:08:59.97
Chris Morrell
Yeah I you know I know that's a big thing for people Honestly, ah it doesn't matter at all to me. Ah, you know I was just um, trying to and it was more like a due diligence thing of well people use these make commands.

01:09:02.81
Mateus Guimaraes
Yeah, see.

01:09:15.30
Chris Morrell
So if I want this to be an appropriate way to to do things I need to solve that problem but I'm kind of like you. It's it's um, and lo. It's rare that I feel like I get much benefit honestly I usually just copy an existing file and start from there.

01:09:30.91
Mateus Guimaraes
Yeah, same yeah I did that as well. Yeah.

01:09:34.38
Chris Morrell
You know, um, or or use Laravell idea. Um, but ah for me I think the the bigger benefit to using modular is um, all the Auto Discovery stuff because that's the thing if you're going to roll your own Modules. You lose a lot of the the really nice convenience that lairvell gives you um I can just drop a new command in my Modules commands directory and it's just Auto registered right? I can just if I just put views in the views. Directory.

01:09:56.34
Mateus Guimaraes
So.

01:10:03.80
Mateus Guimaraes
Yeah, yeah.

01:10:11.60
Chris Morrell
They are just auto registergistered with the correct namespace right? and um, the route I just create a routes file and those routes are auto- registergied right? like all that stuff um is just handled for me and just like Laravele I can peel.

01:10:12.87
Mateus Guimaraes
Yeah, that's awesome.

01:10:28.51
Chris Morrell
Any of that back if I need to and take a little bit more control over it but it gives me that same base starting point and then you know I can go from there and for me that is probably the most important piece of of the patent that. Package modular that we maintain is just like knowing I can new up a module and just go from there and like I don't have to create a service provider and register some new namespaces with Blade and register some new paths with the views or yeah like.

01:11:01.52
Mateus Guimaraes
You know that volume of the boiler plate right.

01:11:07.11
Chris Morrell
All of that stuff. Um is handled for me factories and policies and you know all all of that Auto Discovery because there's a lot of it in Laravelle at this point and for the most part. Um, it's pretty easy to hook into but it's just.

01:11:14.48
Mateus Guimaraes
Yeah, so.

01:11:24.91
Mateus Guimaraes
Yeah, it's too Boilerpl right is to how to go into a service provider red through Config Files resources views that kind of thing. So.

01:11:25.49
Chris Morrell
You have to hook into a bunch of places. So.

01:11:34.55
Chris Morrell
Yeah, yeah, so having to make commands is nice but it's It's really that piece that feels the most valuable to me. Um, and you know that that was kind of my same issue with the ah the lareval.

01:11:37.79
Mateus Guimaraes
So very.

01:11:44.34
Mateus Guimaraes
Niaggregate.

01:11:51.74
Chris Morrell
Modules Package was um, you know because it's not using those same conventions. It has to kind of I don't know I guess it it probably Handles Auto Discovery for you too. But it's just like a little different. You know.

01:12:06.59
Mateus Guimaraes
Yeah I tot know either. But I mean that's my point of thing if you have sometimes to see people saying oh you're you're not following the lava conventions with a modular app but to me if you have a modular app that so has the same directories and the same things in the same places. Um, and. And'm sure I'm not trying to be smart as to me, it's so you know larval it. It doesn't really have anything different. It's just if it's as if you had you know instead of having 1 gigantic or application. You have several smaller applications.

01:12:29.82
Chris Morrell
Um, yeah.

01:12:36.83
Chris Morrell
Yeah, yeah, yeah.

01:12:39.50
Mateus Guimaraes
That's all that it changes to me That's that's that's the only difference that I can see.

01:12:44.16
Chris Morrell
And yeah, but those applications are all inside the same codebase and um, you know can communicate without having to do like ah you know Network Service Discovery and and.

01:12:47.90
Mateus Guimaraes
Yeah, yeah.

01:12:59.97
Chris Morrell
You know Rpc calls and all that stuff.

01:13:00.30
Mateus Guimaraes
Yeah, and and that's what I really love about about modular monolithic applications. You have those really cool bo benefits that you would have in a microservice application without having to deal with the whole you know talking over a network. Maybe having to something like Qrpc or you knowosing Kaf got to do event-driven. Communication between services which I mean if you have a large team and you have someone who can set all of that up and you just code ah in my experience. It was okay, it wasn't you know, super nice, but it was okay now if you don't have that it's it's massy. It's really messy.

01:13:33.85
Chris Morrell
Yeah, yeah, all right I have I have two last things that I wanted to touch on. Um, if you still have a little bit of time. Um, the first one is I wanted to push back a little bit on the don't mix ah Modules and ah.

01:13:41.23
Mateus Guimaraes
Yeah, sure.

01:13:52.71
Chris Morrell
Regular application code. Um, because I you know we we do have both and I actually think that for the most part it makes a lot of sense because in my experience if you look at Other. Um. Modular architectures whether it's like ah um, you know, like ah, a big ah Forum software that has a bunch of different features that you can turn on and off or something like that. There's almost always a core module right? That's just the.

01:14:26.54
Mateus Guimaraes
A.

01:14:30.80
Chris Morrell
Hey this is the stuff that we just can't operate without this existing and um, you know if you look at the way that larall's architected. There's the you know larall support and Laraville Foundation stuff that kind of you know is the same premise.

01:14:42.18
Mateus Guimaraes
A.

01:14:48.33
Chris Morrell
And so for me I really actually like um, having an app namespace and then a Modules namespace and it's kind of like the code there's certain. There's some code that is like application level code and then there's code that's module level code.

01:15:05.00
Mateus Guimaraes
Yeah, yeah.

01:15:07.65
Chris Morrell
And ah, most things don't go into the to the app name space. Um, and at this point in you know our application's lifecycle. Almost nothing goes into the application name space because that core stuff already exists and you know you know there's not.

01:15:21.73
Mateus Guimaraes
And he.

01:15:25.12
Chris Morrell
It's very rare that you're going to add something that's like new core code. But like I said you know stuff around. Ah you know your user models your user and authentication. Um. Particularly in laravell stuff where there's sort of certain expectations about what's going to exist where um, you're just going to have a better time if your main user model is called App User ah than or app models user like laravelle.

01:15:45.67
Mateus Guimaraes
E.

01:15:55.55
Mateus Guimaraes
I.

01:16:02.21
Chris Morrell
Make certain assumptions about like or or other packages make certain assumptions and I find that it's kind of a nice um, a nice way to approach things. Um, because in my experience There is a little bit of code. That's just like application level. Um, that doesn't belong in an individual module.

01:16:21.72
Mateus Guimaraes
Yeah, no I's totally agreeing I think that's fine I think having that that core aspect whether you make it Up. You know a core module or just give it a nap I think that's fine I think the problem is if you try to really mix things and you have certain modules because here's the thing even if you don't have a. Modules Folder if you don't have them logically separated um those relationships still exists right? So if you have an ecommerce software. That's a regular layer of Application. You still have even though you know, um, you haven't artificially created a folder for it and gripped things. You still have a shopping module is to have a checkout module. They're just not clearly Defined. It still exists I think the problem comes when you when you mix those So sure if you have an existing application and you say okay now I think we should move to Modules You can't just dump everything and want to go you have to do that progressively or you know? yeah.

01:17:03.54
Chris Morrell
Yeah.

01:17:14.60
Mateus Guimaraes
Even just move what you think is important and live everything on app. But I think that if you're starting a new application I don't think it makes a whole lot of sense to give some features in Modules and some features in the app name space I think that's confusing. Yeah yeah.

01:17:26.96
Chris Morrell
Yeah, no I agree completely? Yeah, okay so I just I just misunderstood what you were saying. Yeah, you definitely don't want to mix the 2 approaches and I mean you know that's that's still a pain point for us because we introduced ah the modular approach. Well into the the Laraville Application's lifespan and so there are plenty of features that still exist under the app namespace that just hasn't made sense for various reasons for us to extract out and um, it sucks. You know it's just to pain. It's just a pain to deal with um.

01:17:43.87
Mateus Guimaraes
So.

01:18:02.39
Chris Morrell
And every time I I have to work on something that's not ah particularly if it's like the more um, specific of a feature it is where I'm just like oh my God All this stuff is like its own thing but I have to like. Hunt through the whole application namespace to find all the pieces of it. It drives me knots. Um, so.

01:18:25.64
Mateus Guimaraes
Yeah man, you just put it super nicely I Think that's what I was trying to say early in the episode. Even if you have a regular application. You know the fish you're working on is sell its own thing. It's just spread across multiple directorctors and mix with a bunch of things right. That's kind of what I wanted to say but I agree I Think the nice aspect though is you know you don't have to start a project with modular and you can modularize it as you go, you know? Ah I think lots of us already have existing product existing projects and people might think Okay, you Know. Do I have certain new projects to use this? No you can just you know maybe develop a new feature. You can put that in a module and maybe as you go as you have time you start extracting some things into Modules or maybe you just say Okay, it's not worth extracting this and you just live that on the app. Directory I Think that's fine as well.

01:19:19.18
Chris Morrell
yeah yeah I mean 1 other like I try not to um I try not to hype this too much because I I think that it's easy to get kind of caught up in of ah over optimizing for. For an eventual and eventuality. That's never going to happen. Um, but 1 thing that we've definitely done ah with modular that I that is really nice, um, specifically because each module's um, ah. Structure is really how I would structure a typical lairvell package as well. Um, is because your whole thing is like this nice little box. Um, and in the case of modular. It's got its own composer that Json file. It's got its own config vile. It's got its own. Um. Read me potentially ah you can just and it's all under its own separate namespace. You can just rip that whole thing out into a separate package and publish it. You know if if I have a feature that I want to share across 2 different projects I can implement it as a module in 1 knowing that.

01:20:23.35
Mateus Guimaraes
Yeah, yeah.

01:20:32.91
Chris Morrell
At some point maybe maybe this is going to be useful in this other project and I can just pull it out there or you know we have an internal an internal cms um that we use that I you know I just kind of know at some point I want to open source but right now. Um.

01:20:39.98
Mateus Guimaraes
So.

01:20:51.35
Chris Morrell
For various reasons I can't so that just lives in its own module. Um, and at some point to publish it I literally will just grab that entire directory and just copy and paste all those files into a new Git Repo and it's. Pretty much all configured for me already. You know I I'll have to go then you have to go into your service provider and do all the registration stuff because modular is no longer um Auto Auto registering. But it's ah it's just like a cool little pattern especially if you are perfect.

01:21:17.62
Mateus Guimaraes
Yeah, yeah.

01:21:27.89
Chris Morrell
You know if you'd like to open source stuff that you work on. Yes.

01:21:31.34
Mateus Guimaraes
Yeah, right? and I think that that goes back to what we were saying because that that only works if you were mindful of your boundaries right? Even if you don't actively think about that. But if your module talks to a lot of stuff in your application. It's going to break once you remove it? um. So 1 thing that I tried to to make very clear on the course is with with modules you have a box whether it is a black box or whether it is a a white box. It's up to you. You're given a box if you want to make it a black box where no other module even knows excess. You can do that. It's going to be more complicated. You're going to have more trouble maybe for what you do. It's worth it for most of the things that I do It's not worth it. Um, so I don't mind having so references and talking to different modules directlyically that kind of thing but I know that for some people and I have lots of friends. Lots of friends that are working that work in the banking sector. Um, and I know that for some. Specific things they have to be mindful of that. Um I do not so I don't really mind that but um, yeah I think that's super cool I there were a few situations where we extracted things to packages and there were also situations where we extracted entire modules into separate services like separate applications.

01:22:42.60
Chris Morrell
Right.

01:22:44.25
Mateus Guimaraes
And it started doing network calls and and that was a decline because since we had the modules and even though we we were not super strict about communication Whatnot. We still have that going through some services we just extracted the Module. We replaced the services that was an interface. To use the network and it just worked I mean short we had to look at sort sort of things because the network can fail that kind of thing so error handling was a little bit more complicated and um, and for example, you don't have exceptions anymore. Allows you do that on on your um connection layer.

01:23:03.68
Chris Morrell
Yeah.

01:23:20.68
Mateus Guimaraes
So obviously it wasn't just replacing it but it was so so so much easier than you know the other option.

01:23:25.83
Chris Morrell
Right? And that's I mean that's the reality of scale for most applications. Is. You never know I mean I think the reason why so many people got bitten by the microservice Hype is most applications do not need. The the benefits that microservices provide right? like ah particularly the scale benefit of like being able to spin Up. You know as many or as few of any given microservices necessary for your load that sort of thing like most applications are just not going to deal with that. But.

01:23:49.77
Mateus Guimaraes
Yeah, yeah.

01:24:04.85
Chris Morrell
The advantage of sort of starting with a monolith is but modularizing it is if you ever do happen to get to a place where one given Module um becomes a bottleneck in your application like.

01:24:09.60
Mateus Guimaraes
So.

01:24:24.66
Chris Morrell
You then have the opportunity to look at other options and if your application is sort of split into um separate features. You're going to have an easier time of extracting that out into its own service. Or maybe finding a third party that just handles it better at scale for you or you know whatever, whatever the solution may be um, it just gives you more options but most people are not going to need those ah those options until you do and when you do, um, it's hard to know at the beginning. How to prepare for it. But this at least gives you um, a path right.

01:25:08.70
Mateus Guimaraes
Yeah, it makes it easier and it's super flexible right? So you can go super super soft on it and just have the modules and still do your live applications. Maybe you want to go a little bit more in depth and you can start introducing some um, some facades between between modules to ensure. You're not talking to the module internally directly and you're justcoupling. Maybe you're a little bit more hardcore and you start communicating through events. Maybe you're super hardcore in every module. Always a black box that does not know that each other exists you don't share Sql queries the kind of thing you can do pretty much anything and it's super versatile. Um, that's why I find it very hard to answer questions specifically about how you should code within your modules because I don't really know what someone's saving for ah how many people they work with what the company does you know? Ah there's all of that and all of that matters. But the point is that. You can just use the organizational aspect or you can go super hardcore and also think about all these different things and coupling and if you want to extract them if you want to extract them to a package to a different service. All of those things. Um, and I think it's a super versatile pattern I would say right. Um, that I think most projects can then and fit from to some extent at the very least.

01:26:27.64
Chris Morrell
So my last the last thing that I just kind of wanted to open up to you to see if if this goes anywhere is you know you just released this ah this la cast course congrats by the way that's awesome and I know you're talking at Lare County you about moduleization as well, right.

01:26:36.45
Mateus Guimaraes
And thanks, yeah.

01:26:42.67
Mateus Guimaraes
Yeah, yes.

01:26:45.42
Chris Morrell
So I know that like you just this is a thing that you've been thinking about a lot is there just anything else that um you know that you covered in your course or that you're thinking about for your talk that you just we haven't touched on that you you think is worthwhile um to highlight or do you think we kind of covered. Cover the topic pretty well.

01:27:04.46
Mateus Guimaraes
I mean I think ah when I think about about of Modules I Think the organization aspect is is a given and right it comes with modularization by default. But I do think that the coupling aspect is something very important to at least watch out for um and we kind of talked about this a lot. But I guess I'm just trying to reinforce that the way how your modules communicate to one another is is really Important. Um and not necessarily because I'm trying to say that coupling is bad or anything I don't think that ah I say this in the course I think coupling is a spectrum right? So you. It's not, you're either. We talked about this, you're either couple or not. It's It's a spectrum. Um, and you've got to find out what you're comfortable with what your team is comfortable with if you have your large team. You probably want to be less coupled between Modules because you want different people to be working on different Modules If You have a small team. Maybe you're fine with.

01:27:41.12
Chris Morrell
This chore.

01:27:56.38
Mateus Guimaraes
With a little bit more coupling and the kind of thing and it's always a tradeoff right? So you're trading something for that load coupling. Maybe you have more but more boilerplate. Maybe you have a little bit more interactional layers which makes your code up. For example, an event-driven Codebase. It's harder to know what he does because it's all through events so you don't go into. Class and you say okay this class called Class B that calls class C. It's this class dispatches an event and I don't know what it does over there. So um, but I do think it's It's very important to.

01:28:22.33
Chris Morrell
For sure.

01:28:28.56
Mateus Guimaraes
And I don't know how to put this into words because it's like sy do by default and I think you do too the time that you have those modules you you just think about them. You go? Okay, maybe maybe you know your exams module. It has to talk to this certificates Module What is the best way to do this right. And sometimes it's just having a relationship on your model because you know you're isn't eloquent Sometimes we try to if you're using a when you have to abide with certain things I think and make your life easier and sometimes you're just adding their relationship on your model. But ah, sometimes maybe you want to have a service in the Middle. An interactional layer that makes a little bit more complicated but learn some good results. Um, so I don't know if I'm making any sense I'm trying to but it's it's It's very Abstract. Um.

01:29:20.42
Chris Morrell
No I think I get what you're saying just just that ah a valuable consideration when you're when you're thinking about Modules is what's the you know what are the tradeoffs between sort of ease of use and coupling.

01:29:30.64
Mateus Guimaraes
Yeah, yeah, exactly and I think that comes by default when you when you start doing Modules you start thinking about that by default.

01:29:36.68
Chris Morrell
And complications. Yeah, yeah, no I get that nice. Um, okay, well this has been awesome. Is there anything else that ah that comes to mind before we we start to close it up.

01:29:54.19
Mateus Guimaraes
Ah, no I think I think we searched on the on the most important the most important subject.

01:30:00.48
Chris Morrell
Well, it's been ah, it's been awesome. Having you on and this has been a great conversation I you know I really I know that when Daniel worked here. Ah you know he said to me a couple times like the thing that I try to. Bring to every client that I work with now after working in internetche is like modular and ah yeah, yeah, it's just like it's one of those things that once you get a feel for how nice it is. It's like you want.

01:30:19.79
Mateus Guimaraes
It took me. You learned not long ago like a week ago or so.

01:30:34.67
Chris Morrell
You want everyone to know about it. Um.

01:30:35.39
Mateus Guimaraes
Yeah that's a feel man. It's like when you want your friends know about Tim and you go and say Chris Chris tried this Chris write this Chris ride this and they're like nah. Not really no, you know and until you convince them to try for the first time and if they like it usually goes super well right. But getting them to try it that that's where think things are a little bit hard. So.

01:30:54.39
Chris Morrell
Yeah, and I think the problem with this is it's like it's not sexy at all. You know it's like I I can tell you oh you should try out like um, you know I remember when Aaron Francis's sidecar came out and it's like this amazing. Ah.

01:30:59.80
Mateus Guimaraes
Yeah, yeah.

01:31:13.90
Chris Morrell
Thing to handle like these lambda calls for you and it's just like that's an easy pitch to anyone to check out because it's fricking cool and it's you know, just like flashy and you can imagine all these different use cases whereas moization is just like oh this is just going to make you have. Ah, better time in general with but like that's it right.

01:31:37.66
Mateus Guimaraes
Yeah, and also I think I mean I think as as developers we like complex things we we want to write complex code that kind of thing and I don't think Modularization is very complex like at its core it starts by creating a new name space and you take it from there. So.

01:31:44.15
Chris Morrell
Sure sure.

01:31:55.56
Chris Morrell
Right? Yeah well I hope that at least a few people check out one of these approaches. Um, based on this conversation so you have ah you know this course on laircast. What's what's the.

01:31:56.30
Mateus Guimaraes
Doesn't have that appeal for sure.

01:32:13.40
Chris Morrell
Best way to find that just I guess ah it's called Lareve Modules Modular Larall on anlycast.

01:32:14.72
Mateus Guimaraes
So yeah, it's called it's called modular laravo yeah yeah I just go to lacast to come. It's on the homepage. It's it's the latest course. So it's on the top of the homepage. Um, it's a 26 lesson course 3 and 3 3 three thousand and a half I think um.

01:32:30.80
Chris Morrell
Yeah, 3 hours and 31 minutes

01:32:33.27
Mateus Guimaraes
And he goes from the very basic. Yeah, it goes from the very basics. Um, we go a little bit overki at some points just to to showcase a possible solution and we we go through everything how to create modules how to talk between modules we cover. Ah. The modular package by internaci we cover larville modules we cover Lareville idea. Um, we talk about grouping by type grouping by feature vertical slices. Ah domain- orientied um modules as well. Event-driven communication. We cover a bunch of things you're probably not going to use. Even a third of them. But it's good to know.

01:33:07.54
Chris Morrell
Awesome! Well thanks again and until next time.

01:33:11.70
Mateus Guimaraes
Awesome Dude Thank you for having me This was really really cool and I'm really nervous still. But.

01:33:14.82
Chris Morrell
Awesome. You did great.