Skip to content

Conversation

@trenpixster
Copy link
Contributor

Besides my comments and apart from naming the only thing that struct me a bit oddly was the folder structure and file naming. But I see many advantages in having the Entity model folder as the root folder for all the interactors, repository and whatnot. I'd prefer to have the files for each use case/interactor available separately though, for the same reason that I liked the way the Entity named the root folder: visibility over what those files responsibilities.

As I said in the comments, I also see advantages in having more comprehensive and better split tests. Here's a very nice article from Martin Fowler on tests architecture: https://martinfowler.com/articles/microservice-testing/meta-image.phttps://martinfowler.com/articles/microservice-testing/meta-image.png

"""Adapter to use Django ORM as a storage backend."""

def create_user(self, user, password):
# not injecting repo makes it less explicit when testing
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you mean what you call repo_provider in your code? So the User.objects here?

django_user = accounts_models.User.objects.from_entity(user)
django_user.set_password(password)
django_user.save()
# nizar: unnecessary coupling with the return from the repo;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed, I prefer a function that takes a model as an argument and returns the entity.

raise self.DoesNotExist('User {} is not joined to board {}'.format(user_id, board_id))

django_board_user.delete()
# nizar: interesting choice here, not sure why it returns this kind of object
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah this should return an entity to be consistent right?


from .storage import Storage

# nizar: very cool exercise for leveraging the advantages of having a common interface for a repo
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah this makes it clear why you want to abstract the repository so you can switch between django storage and memory storage easily and test the business rules.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants