Where to place a common database connection in clean architecture?

Question

I am currently trying to follow the clean architecture approach but i wonder where common things like a database connections should take place.

Since i think a database connection usually will be opened once, but different tables in there are used from feature to feature in different ways, it wouldn't make much sense to implement (even as a singleton pattern) for this in every feature that will be developed.

But the almost every example (at least for my current flutter application) i found is exactly doing this. The database instance is being created in a feature itself.

Especially when looking at a library like Drift, that is generating only one common file for the database connection and the used tables, its really hard for me to get it to the right place.

Were should something common like the database connection should go into? Indeed in every feature? In the core space?

Answer 1

I am currently trying to follow the clean architecture approach but i wonder where common things like a database connections should take place.

Right here:

Since i think a database connection usually will be opened once, but different tables in there are used from feature to feature in different ways, it wouldn't make much sense to implement (even as a singleton pattern) for this in every feature that will be developed.

A "feature" isn't an architectural thing in Clean Architecture. Sorry but it just isn't. The closest Clean comes is the use case. Package by feature is a good idea. It's just someone else's idea.

That said, you can be feature centric and still use Clean Architecture. Heck, each feature can have it's own onion.

But the almost every example (at least for my current flutter application) i found is exactly doing this. The database instance is being created in a feature itself.

Which is fine. But it's also not something Clean Architecture speaks to. Clean Architecture is a dependency diagram. It shows you what statically knows about what. It doesn't show you how to build it. Just what it should look like when you're done.

github.com - esakik

Can you look at that and tell me if Data Access is a long lived object that was built in main() ^{(Who needs singletons?)} or something that the Use Case Interactor had built just now? Nothing in these diagrams answers that question. So you're free to do it either way and can still claim you're following Clean Architecture.

Why DB is then put on the outer circle when it should be accessible from the entities? Jim Panse

The DB is accessible from the entities. Remember, this is a dependency diagram.⁼ Not a data flow diagram.⁼⁼ Those black arrows going into the circles don't mean this is a roach motel that traps you inside.

Uncle Bob tried to make that clear with the little "Flow of control" diagram in the lower right corner. Notice Presenters dependency arrow points to Use Case Output Port but the Flow of control goes exactly the other way. That's what they call dependency inversion.⁼⁼ Because of that, control can dive into a lower layer and come back out. _{All without using return!}

And if you can do that, you can do this:

crosp.net

So don't feel like you have to do this:

slideshare.net
youtube.com - The Principles of Clean Architecture by Uncle Bob Martin

By the way, Casey Muratori is a game dev with a focus on performance who has been critical of some of Uncle Bobs teachings. You can see them hash it out here. It's a really good read and a good reminder that doing stuff this way isn't free.

Answer 2

Reading the question and the (very good) answer of @candied_orange, I'd like to add something.

A lot of people think of a database as the most important and centralized part of an application. That's a common mistake, fed by the marketing departments of the database manufacturers. The database is not the main part, it's just a detail; the most important part of the application is the implementation of the business rules and features (i.e., the code), and the database is just something to store the data to be processed. A file storage, or a REST API storage (or plain old stone tables ;-)) could also do the job.

That's why Uncle Bob says that the database is just a detail and should be hidden behind a storage adapter or Data Access Component (DAC).

So, what is the 'right place' to put a database connector? Since we need only one database connector for one database, we should make sure that the database connector is instantiated once (especially when initializing the database takes time), but accessible for the components that need access to the database. The exact implementation depends on the language (C#, Java, dart) and frameworks used.