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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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.