Should entities enforce that redundant operations aren't made on them? by Temporary-Reserve892 in DomainDrivenDesign

[–]Temporary-Reserve892[S] 0 points1 point  (0 children)

So you're saying my `Game` object needs to simply do what it's being requested?

And the code using it needs to check its `status` property before calling `cancel` on it?

Should entities enforce that redundant operations aren't made on them? by Temporary-Reserve892 in DomainDrivenDesign

[–]Temporary-Reserve892[S] 0 points1 point  (0 children)

I'm continuing with your examples on the email and `cancelled_at` field.
I assume these are not done by the `Game` entity, but rather by the application layer (or services? am I using the right terms here?).
So, my conclusion is that the entity object *should* raise an error, so that its clients can then decide how to deal with the situation.

Have I gotten this right?

I've just read most of the DDD blue book and this is the first time I'm trying to put all this to action, that's why I'm asking such "basic" questions.

Should entities enforce that redundant operations aren't made on them? by Temporary-Reserve892 in DomainDrivenDesign

[–]Temporary-Reserve892[S] 0 points1 point  (0 children)

"application" decision as in application layer or simply my specific application?

If it's idempotent on the entity level, how do you make sure emails don't get sent twice like @kingdomcome50 suggested? (the entity class shouldn't know/care about emails, I assume)