You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I think that this factory should not exist in the core domain layer since it injects the knowledge of Firebase in that layer, which should be completely agnostic to specific technologic choices.
As I already commented here, this could be avoided by using a different approach in structuring the project.
A per-feature splitting would let to insert this UniqueId.fromFirebaseId factory in the domain layer of the auth "package" so to say, imagining to have a FirebaseUniqueId object that inherits a common/core generic UniqueId one.
The text was updated successfully, but these errors were encountered:
The naming of this factory is quite unfortunate. I should really fix it to not be Firebase-specific, but even now, this factory logic doesn't have anything to do with Firebase. It simply takes any String and trusts that it's unique. Perhaps renaming the factory to fromIdString would do?
The purpose of this factory should be to create a UniqueId object from a string that we trust and we know is already unique.
So, maybe you could call the factory UniqueId.fromTrustedString or UniqueId.fromUniqueString.
I think that this factory should not exist in the core domain layer since it injects the knowledge of Firebase in that layer, which should be completely agnostic to specific technologic choices.
As I already commented here, this could be avoided by using a different approach in structuring the project.
A per-feature splitting would let to insert this
UniqueId.fromFirebaseId
factory in the domain layer of theauth
"package" so to say, imagining to have aFirebaseUniqueId
object that inherits a common/core generic UniqueId one.The text was updated successfully, but these errors were encountered: