2

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?

19
  • To get it to "the right place?" What is the "right place," and why is it hard for you to get "it" there? Apr 19, 2023 at 0:05
  • The right place for me is somewhere where i can access it from anywhere else, since every feature somehow need the database connection itself but indeed not the same tables .. therefore its hard for me considering a new data base connection in every single feature ... maybe i also do net get the idea of clean architecture right, where db connections sit on the same level like web and UI
    – Jim Panse
    Apr 19, 2023 at 11:15
  • See this diagram. If you want something to be accessible from any ring, you have to put it in the center circle. The inner rings can't access anything in the outer rings (the Dependency Principle), so putting it anywhere else will exclude it from some your features. Apr 19, 2023 at 11:35
  • 1
    Also, keep in mind that a lot of modern architectures, including this one, are designed for very large applications, written by teams of developers. If your application is not Facebook or Youtube, you may not need this at all. Apr 19, 2023 at 11:49
  • 1
    My advice is to simplify. Apr 19, 2023 at 11:50

2 Answers 2

2

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:

enter image description 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.

enter image description here 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

enter image description here

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.

enter image description here

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:

enter image description here crosp.net

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

enter image description here 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.

1
  • This is an amazing answer to my question! Thanks a lot!
    – Jim Panse
    Apr 23, 2023 at 8:41
0

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.

1
  • There is an important caveat to this: Persistence is often the slowest part of the application, and also commonly the location of concurrency. A plain file storage would get corrupted the first time two instances of the application attempted to persist different versions of the same entity, and would be horribly slow the first time you tried to look up 1 entity in 1 million. As such, the choices made in how you do persistence can have far more significant impact on non-functional requirements like performance and data integrity than how you write your business rules. Apr 22, 2023 at 23:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.