TLDR;
This video addresses the question of whether implementing repository and service patterns in software development is considered over-engineering. It suggests that the decision depends on whether a framework is used and, if so, whether the chosen patterns align with the framework's conventions. The video advises using the default patterns provided by the framework when possible and determining an appropriate architecture for the company when not using a framework. It also cautions against being too rigid with one architecture, as different companies may have different styles.
- Use framework's default patterns if possible.
- Determine architecture for the company if not using a framework.
- Don't be too rigid with one architecture.
Question About Over-Engineering [0:39]
The video begins by addressing a question from Putuyaza about whether implementing repositories and service patterns is considered over-engineering. The speaker explains that when developing software, the choice of programming language is crucial, and companies often opt for popular frameworks to avoid recreating existing solutions. These frameworks typically come with their own patterns, which the speaker recommends using.
Framework Patterns [1:32]
The speaker suggests using the framework's pattern if one exists. For example, frameworks like Laravel, Ruby on Rails, and Django use the MVC (Model-View-Controller) pattern with Active Record for database interaction. In contrast, the Spring Framework typically employs a controller-service-repository pattern. The speaker advises following the framework's conventions and avoiding forcing patterns that are not native to it.
Framework vs No Framework [5:09]
The video then discusses scenarios where a framework is not used. In such cases, the company must determine its own patterns. The speaker cautions against overly manual approaches where all logic and request-response handling are concentrated in a single file, as this can lead to maintenance issues. Instead, the team should agree on an architecture, such as clean architecture or hexagonal architecture, or adopt familiar patterns like MVC or the controller-service-repository pattern.
Over-Engineering Considerations [8:07]
The speaker revisits the question of over-engineering, suggesting that it depends on the framework being used. Adding services and repositories might be considered over-engineering in frameworks like Laravel, where it's not the default approach, but it's standard in frameworks like Spring. The speaker also mentions alternative simple approaches, such as using handlers and use cases in clean architecture.
Conclusion [10:05]
The video concludes by emphasizing that whether something is over-engineered depends on the framework used. If not using a framework, it's crucial to determine the right architecture for the company. The speaker advises against being too rigid with one architecture, as different companies may have different styles. It's important to adapt to the conventions of the specific environment, unless one is in a position to collectively decide on the architecture from the outset.