0

I am currently facing a few issues when implementing the logic in one of my Aggregates.

Imagine an "Account" aggregate, which has email, password, verified and verificationDate fields (basically credentials and verification status).

When a new Account is created, it has verified = false, and verificationDate = null.

The email should be validated: an account cannot exist with an invalid email (abc@ is invalid). The password should be validated too, and encrypted.

The issue is: if the validation happens when constructing the Aggregate, it would be triggered everytime it is returned by a repository. I've thought of putting that logic in a service, but then it would be possible to create an invalid Account if I bypass the service.

Where should this validation / transformation logic happen ?

KSR
  • 101
  • Where it makes sense for it to happen. – Robert Harvey Oct 13 '21 at 22:35
  • It's better to think of the Account aggregate as an inner layer sort of thing, where you assume that if you get an instance, it's already a well-constructed, valid instance - and then have the surrounding code that passes it in make sure this is the case (even if the data is coming from the DB). Since the users need to verify the email, perhaps you need an additional concept "PendingAccount", and then require your Accounts to be constructed from a verified PendingAccount. The Account aggregate itself should just check if the data is well-formed. – Filip Milovanović Oct 13 '21 at 22:43
  • Don't store encrypted passwords, that's a security risk; compute and store a cryptographic hash instead. – Filip Milovanović Oct 13 '21 at 22:43
  • Aggregate means a class containing one or more other classes, not fields. – radarbob Oct 14 '21 at 02:35
  • *[validation] ... would be triggered everytime it is returned by a repository* : That is a good thing. The point is creating a correct, valid object. What business is it of the created class (constructor) to know or care where the data originates? If you do not want invalid email data corrupting or aborting object creation then an Email class is a good idea. - THAT would be aggregation. – radarbob Oct 14 '21 at 02:46
  • What does it mean for a password and email to be validated? – Bart van Ingen Schenau Oct 14 '21 at 08:30
  • Thank you all for your comments. @radarbob my problem was certainly badly stated, but the thing is: if I want to recreate my aggregate from the repository, I might need to implement a constructor/factory having every attribute, which would let the possibility to create a new Account with verified=true. verified should always be false when creating a new account. So how can I have this invariant enforced, and have a way to instantiate an Account with all its attributes from the repository ? – KSR Oct 14 '21 at 23:55
  • I'm reading a hesitancy to use a constructor, their purpose is to set object state during initialization. Why ever I would not use a constructor to control initial state I don't know. There's no rule that says a constructor cannot ignore or override part or all of constructor arguments. – radarbob Oct 15 '21 at 04:26

0 Answers0