DEV Community

Discussion on: Practicing YAGNI

Collapse
 
sequoia profile image
Sequoia McDowell

Abstracting external dependencies: External dependencies add complexity to your project.

This can very quickly be taken too far. I might add: "Abstracting external dependencies adds complexity to your project."

  • "Let's abstract away our relational database so we can easily switch from MySQL to postgres"
  • "Let's abstract away our ORM so we can more easily switch to another ORM"

These are cases where YAGNI should absolutely be practiced. Eventually you have to base your application on something concrete, i.e. a particular DB engine or programming language; trying to abstract these things away completely is a waste of time.

Furthermore, excessive abstraction can make it hard or impossible to actually use a tool effectively. For example, if your ORM provides pagination but you abstract away the ORM (using "repository pattern" or some such), you now have to reimplement pagination in your application code, or pass everything through, effectively rewriting the ORMs API.

I think YAGNI is the perfect philosophy when asking things like "What if we want to switch from MySQL to MongoDB?" To wit: you are probably never going to want to do that, and if you are, it's probably cheaper overall to just do the rewrites at that point than using some hobbled db abstraction layer that provides crappy SQL support & crappy mongo support but technically "supports both."

Thanks for the food for thought!

Collapse
 
shalvah profile image
Shalvah

Word. :clapping:

Collapse
 
iamkevgarcia profile image
Kevin Callejas

IMHO, You should keep decoupled your domain layer from the infrastructure layer.

It's not about "What if we want to switch from MySQL to MongoDB?", it's all about of separation of concerns. For example, by applying "Dependency Inversion", it only takes a few minutes (sometimes 1, YMMV) to create a domain interface and then create the implementation in the infrastructure layer, although you know that you aren't going to change the DB next month (Be careful here, because applying this principle everywhere is an example of over engineering, we're in a separation of concerns context).

As Jason McCreary says in the article, external dependencies add useless complexity to our domain and that boilerplate code will give us a lot of headaches when business people will ask us to add some features to the already existing use cases.