State in domain services

[ErikJson]

Hi,

In the book, it's clearly stated that domain services should be stateless. However, we noticed that BusinessPriorityCalculator (and possibly other services) do store a repository reference.

We can see why this may not be an issue in practice, given that BacklogItemRepository should be a singleton, but we don't know if that's the reason why this exception was made.

What rules of thumb do you use when sidestepping the "services should be stateless" rule? Thanks!

[VaughnVernon]

It's free of business state. Technical state is fine, and it's typical for a Domain Service to use a Repository.

[ErikJson]

Thanks for your response, Vaughn.

The terms "business state" and "technical state" are a bit vague to me, and I can't find good resources on them. As far as I can tell they are not covered in the book.

We believe ourselves to have a decent understanding of what can and cannot be stored as class properties on the service, e.g. we wouldn't think to store the tenant or product IDs as properties on BusinessPriorityCalculator, so we'll proceed with the assumption that we can trust our judgment rather than a set of clear rules.

[VaughnVernon]

Your assumption is correct. Associating any business-specific data (model objects) with a Domain Service beyond a single operation is the wrong decision.

A Repository is technical state to make it convenient to use one or more Aggregates in the business operation.