Full transcript of “Over Engineering”. Click a timestamp to open the video at that moment. Need another video? Use the YouTube transcript generator.
0:01 Okay, if we make a project, there are a lot of pattern designs that we can use, right? Or, eh, each person's style can sometimes be different, or even each company is different. There are those who use talk, for example, just use MVC, for example. Some add a service layer, some add a repository layer and many others. So, the question is, if we use those architectures, is that kind of design code over-engineered or not? Would it be better to have a less complex version or a simpler version ? Well, there is a question about that, right? Come on, let's look at the question. Okay, this is a question from Putuyaza. Over-engineered. Sir, I want to ask whether implementing
0:46 repositories and service patterns is considered over-engineering. Many people say this is over engineering when I use this pattern. Well, if you would please explain. Thank You. Okay, let's explain. Well, when we make software, for example here is the software we want to make. Well, it's certain that we will definitely determine the programming language. On average, in companies, sometimes, for example, if the technology in programming has a framework that is already popular, they will usually use the framework. Well, why? so that the framework does not have to be created again. So, to use a common framework, it usually comes with the framework. For example, the framework.
1:32 Well, if the case is that there is a framework, then I will recommend it. The recommendation is that we use this framework pattern. So don't make your own pattern. So we can use the framework's pattern. For example, for example, for example, for example, it's like this, it's simple . Well, for example, for example. So, for example, if we use a framework, for example Laravel. This means it's as simple as just MVC, so just the model, view and controller, for example, like this. Well, actually this is enough, it's actually okay to start the initial project.
2:19 Well, the model here is, eh, coincidentally, Laravel uses a pattern called active record, right? So the patent model is, eh, it is an active record, right? Well, it's like this. So this is a pattern, yeah. Well, then eh use the view and usually the logic e controller contains the logic. Well, usually it's like this for Laravel. Well, let's take another example. It's almost similar, there are many like this, right? For example, maybe something like Ruby On Rails . Well, does Jengo seem almost similar? So, he uses MVC, the point is that the database interaction is in the model, right? He uses active record. Then in our application logic, it
3:05 is in the controller section. Well, it's like this. Well, but if you guys are using an EE framework that doesn't have this style, then my advice is not to force it. For example, there is the Spring Framework, for example. Well, usually his style is to use the controller then go to the service then to the repository like this. Well, if it's like this, friends, please follow it. Don't force us to make an active record model, for example. No. We just use the repository pattern. Use service patterns for the logic, then use a controller to just handle the ee here, requests and also responses for the web. So let's just follow it.
3:50 So, is this over-engineered? In my opinion, if the framework encourages us to use it, it would be better than if we all had to do it manually. We've used a framework for everything, but we have to do it manually. So there's no logic in the controller, for example, not creating a repository, for example. Even though the framework already provides features to make this easier. Well, unless you put a pattern that is not native to the framework. For example, friends use the active record pattern in the Spring Framework. That's not a common thing. What is common in the Spring Framework is using the repository pattern. So it doesn't use active record like in Laravel, Ruby Onrels or Jengo. Likewise, the opposite is also true,
4:35 for example. Well, when friends use Laravel, for example, there is already a model, for example. Well, it's very rare, for example, that usually, at the start of the work, the programmer immediately applies the repository pattern or service pattern. It's usually rare in the beginning. Well, except for those that are already complex, you already understand what the service pattern is for, what the repository is for. Well, maybe sometimes it is combined when there is a need. But when we don't need it at the beginning, we just use the default from the ee framework. Well, including other frameworks. Well, the real homework is not when we use the framework. So, it's simple, right? If we use a simple framework, we use the default patterns from the framework. Well, the question is, what
5:21 if, for example, uh, okay, I delete this framework here, for example . Well, this is what we do if we don't use a framework. Well, it's like this. So, this is what happens if you use a framework, for example. So, what if you don't use a framework? Well, if we don't use a framework, we have to determine the EE patterns in the company. So, like it or not, this will happen if you don't use a framework. If you don't use a framework, you will inevitably have to determine patents in your company. For example, friends, just use this ee, shake it. Hey,
6:06 friends, you don't use a framework in your goleng, for example, everything is built by yourself or using Node GS and you don't use a framework like e NESGS, for example. For example, if you don't use pure notode js, just use express, for example, like that, then sequelize and so on. So we sew it ourselves, for example, if we sew the goleng, for example, we sew it ourselves, or even if our friends use Java but don't use spring, for example, so we sew everything ourselves. Well, that's also the question, which pattern should you use? Well, if this is more like ee, don't be too manual, okay? For example, friends only create one ee file for the handler, then all the logic is there, all the request responses are there, they pile up there. Well, that
6:52 will also be a homework in the future to maintain it. Well, in cases like this, you have to decide which patent you want to use. Well, the pattern is simple, right? Yes, it just depends on the agreement from the team at the company, for example. Okay. Uh okay, I want to use the architecture. For example, use clean architecture. Well, there they use the term, like there's infrastructure, right? Actually, it's similar to the controller service repository, only the terminology is a little different. So or friends want to use eh hexagonal sorry hexagonal architecture which is similar to e ken architecture or friends okay because previously I used eh previously I was for example a
7:38 Laravel or Ruby Onrel or Jengo programmer. Ah, I want to use the usual patents that are already familiar, for example, just using MVC, that's fine, no problem. Or if I previously used spring , for example, now I want to use a pattern that is common in spring . So later I will use ee controller, service, and also repository like that. Yes, it's similar to clean architecture or hexagonal, it doesn't matter . Well, this is what happens if you don't use a framework. Well, whether you like it or not, you have to decide for yourself. Well, if the one who asked earlier, ee, who asked earlier, which one of ee Putu Yaza, for example, or his friends, for example, said that this was
8:25 over-engineered. Well, it's better to take a look first if it turns out he's using a framework like Laravel, for example, then of course if he adds services and repositories at the beginning of development, it looks like over- engineering. Even though maybe in the future we'll think, oh so that later all the database logic won't pile up in the model, so that the model doesn't become finished. Eh, the name of the concept is God model, yes god object sorry. So the object is too big. So we separate it into the repository. Yes, maybe we have a plan for the future, but later when there are one or two models that are too bloated, we will release them to the repository. Or maybe in the future, it will be logical so that it doesn't pile up on the controller like that. We separate everything to ee service. Maybe the initial intention was good, but if the
9:11 logic was simple at first, then it's no longer necessary. Later, when the logic is bigger, we will take it out and save it in the service layer. Well, it could be like that. Well, but if you've been using Spring from the start, for example, it shouldn't be possible to call it over- engineering because from the start, the Spring framework has been using the concept of services and repositories. Well, so it's possible that adding services and repositories is considered over-engineered, it's possible that the framework used isn't something like Spring, but perhaps something like Laravel, Ruby, Onril, Jengo, or even Goleng, NotJS, and Java. Well, if this is also good, which one do you want to use? There are simple ones just handlers. After that, eh, in the handler, use this, eh, e use case.
9:58 In clean architecture, the name is use case, for example, not service. Then after that, query the database directly there, it's simple and free. So, whether over-engineering is good or not depends on the framework used. If it's outside the framework, it's definitely over- engineered. Even though we have long-term planning, we'll talk about it later, okay? So, I'll think about it later if it's time to change it, okay? But in the beginning, it's better to use the default from the framework. Well, if we sew it ourselves, please determine the right architecture for the company. Remember, each company can be different. So friends, be careful if you are too, ee, too stubborn on one architecture. Because when friends move, it turns out that other places are different. Well, friends, you
10:45 might end up bringing your style to a new place and it might not suit you . So each company can be different. Friends, just adopt it at place A, use style A, just follow style B, just follow it. Well, that's it. Unless this is just the beginning and friends can decide together what kind of architecture they want to use.
