2

I am struggling with the clean architecure. I have constructed a minimal example of how a usecase/interactor could talk to the database without being dependent on it:

The use case:

class SaveDatatoDBUseCase:
    def __init__(self, AbstractDB):
        self.db = AbstractDB

    def execute(self):
        self.db.save()

The gateway:

from abc import ABC, abstractmethod    
class AbstractDB(ABC):

    def __init__(self, value):
        pass

    @abstractmethod
    def save(self):
            pass

The Implementation for the Database:

class DBImplemtation(AbstractDB):
    def __init__(self):
        pass

    def save(self):
        print("INSERT INTO TABLE WHERE ...")

Wiring it altogether:

if __name__ == "__main__":
  dbImpl = DBImplemtation()
  save_to_db_Usecase = SaveDatatoDBUseCase(dbImpl)
  save_to_db_Usecase.execute()

yields to:

INSERT INTO TABLE WHERE ...

Is this how the communcation works between the UseCase/Interactor and the Database or I am I missing something here? I added a picture to clarify what I wanted to achieve with the code.

Can someone please confirm, whether this is a good minimal approach and if not, where I got this wrong or even what could be improved. Thank you in advance.

This is what I wanted to achieve

Improve this question
1
  • You are in the right path. What you named Gateway is often named Repository, Store or DAO, but this doesn't change the overall picture. UseCase -> Data Access Abstractation <- Data Access Implementation Commented Mar 3, 2019 at 22:46

2 Answers 2

Reset to default
3

Here's your problem:

class SaveDatatoDBUseCase: def init(self, AbstractDB): self.db = AbstractDB

Your use case knows the DB exists. Oh sure this is a semantic nit pick but please understand, all these added layers are a complete waste of time if you don't use them to abstract away these details. The use case doesn't care that a DB exists. It cares that it can send info out to, something, and get that info back, somehow. It doesn't need to know or want to know what that thing is. If you do all the extra work that CA requires and don't do that you'll break my heart and waste my time when I work with your code.

Saving to the DB isn't a use case. Saving, to something, is a need a use case might have. A use case might be "create user". When creating a user, among other things, you need to record info. The use case doesn't care if it's to a file, a DB, or a tape record. Now something, somewhere, has to know those details. Between the use case and the DB should be something that hides those details and provides an interface through which to send info.

What the use case needs is some persistence solution. It shouldn't care what kind. The names you use for the solution in the use case should reflect that.

I mean, you don't have to do that, but if you don't, why do this CA crap at all?

Improve this answer
-1

Is this how the communcation works between the UseCase/Interactor and the Database?

Yes

Improve this answer
2
  • 3
    Answering an "or" question with "yes" is not particularly helpful. Commented Oct 21, 2024 at 12:50
  • 1
    indeed. I overread the "or". Fixed it. Commented Oct 23, 2024 at 10:29

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.