Ttdfjt

Suppose I want this on my User entity:

user.createNewSecurityToken();

That means:

public void createNewSecurityToken() 
 var buffer = new byte[32];
 new RNGCryptoServiceProvider().GetBytes(buffer); // <--- here's the issue
 this.Token = Convert.ToBase64String(buffer);

This is not a DI dependency, just a class from the infrastructure. But does that "break" DDD?

The alternative is this:

user.setSecurityToken(token); // pass it in (probably from a domain service)

But that leads to anemic entities.

Which is the preferred DDD approach, and what considerations should I take into account when faced with this sort of design decision?

UPDATE

Based on comments below, this leads to a more general question: what can I / can't I use in an entity? Domain services, application services, infrastructure services, framework classes, etc. - I know I can't inject DI-based services, or use infrastructure services, but what about the rest? What should I not use inside an entity?

Think of it this way, which one represents something meaningful in your domain? Something that somebody familiar with the domain (but not necessarily the technology) would understand. I.e. which one is more likely to be part of the Ubiquitous Language?

Option #1: setSecurityToken()? Seems technical, it's a setter.

Option #2: createNewSecurityToken()? Seems better, similar words may be in your requirements somewhere? Still it is a bit technical, but might be ok for your domain.

In general what you "can or can not do in an Entity" depends on who you ask. Some people prefer purely anemic entities containing "pure" data with services containing all the logic. Others, me included, prefer a model based on behavior strongly mirroring the Ubiquitous Language, with no anemic objects (i.e. data) nor services (i.e. procedures).

To be honest, most of the examples on the 'net and books (Vaughn Vernon et al.) prefer the anemic object/service (i.e. data/procedure) approach, with some minimal behavior sometimes sprinkled in that can not require any dependencies. This is probably what would be most familiar to other people.

If you want to avoid anemic entities, i.e. embrace object-orientation, you will have to think for yourself, as there is very little about it online. Here is a presentation of mine on the topic.

With a DDD approach you are trying to match your Entities with the 'Domain Language'.

I find it hard to believe that the business says "A User creates a new security token". If they do then sure, the User object should have that method and the required logic for doing the job.

But I think it would be more usual for the Business to say "The User logs in" and for the devs to say "The Auth service creates a token for users".

So now you have User.LogIn() and AuthService.GenerateToken() If they are in the same Domain then you can have one reference the other, but that seems unlikely. in which case the AuthService is a Domain Service.

Which you could either inject into user or User's Aggregate Root to enable the LogIn() method.

Or, you could re think the Domain language and say 'does a user log in? or does the AuthService authenticate the User? allowing you to remove the LogIn() method from user and follow what is now a pretty standard approach of moving all the Auth concerns out of the Domain.