Design problem for DDD and User entity implementing Symfony's UserInterface

2
votes

Why Symfony docs suggest to implement UserInterface interface on my domain User entity?

https://symfony.com/doc/3.4/security/entity_provider.html

class User implements UserInterface, \Serializable {}

To me it looks like this is breaking a basic DDD approach because my domain entities should never rely on something that resides outside the domain (in this case UserInterface is a Symfony component).

The problem is that Symfony's UserPasswordEncoder need UserInterface object to retrieve salt/password from users.

At the moment I have a very sketchy solution that it is not bullet-proof/scalable at all, so I'm looking for solutions.

Do I need to implement my own UserPasswordEncoder that can work directly on my Domain User entity?

1
phpsymfonydomain-driven-design
You could do that and inject it as a dependency – sietse85

1 Answers

1
votes

To me it looks like this is breaking a basic DDD approach because my domain entities should never rely on something that resides outside the domain (in this case UserInterface is a Symfony component).

Theoretically speaking you are correct. Your Aggregates should not depend in any way to the Infrastructure.

Many frameworks are focused on enabling fast delivery of software, not on clean code. From what've seen, Symfony is more suitable for CRUD Entities, in simple domains, not for complex domains where DDD is more suitable. This means that maybe you should not use DDD in this domain, and maybe a CRUD entity would suffice.

Or maybe, if you think the User should indeed be a DDD Aggregate because it has complex behavior, then you should extract the UserPassword into its own CRUD Entity, that is not bound to DDD restrictions. Then, in your User Aggregate, you refer to the password only by ID, i.e. private $passwordId;.

Do i need to implement my own UserPasswordEncoder that can work directly on my Domain User entity?

I think this would be the same thing as the framework's component, at least from the DDD point of view. The password hashing is an infrastructure component, no matter who's implementing it.