DDD domain services: what should a service class contain? -

in domain driven design, domain services should contain operations not naturally belong inside entity.

i've had habit create 1 service per entity , group methods inside (organization entity , organizationservice service).

but more think it: organizationservice doesn't mean anything, "organization" not service, it's thing.

so right have add organization deep copy functionality duplicate whole organization aggregate, want put in service.

should do: organizationservice::copyorganization(o)?

or should do: organizationcopyservice::copyorganization(o)?

more generally: "service" abstract concept containing several operations, or service concrete operation?

edit: more examples given first 1 wasn't good:

• strategyservice::apply()/cancel() or strategyapplicationservice::apply()/cancel()? ("application" here not related application layer ;)
• carservice::wash() or carwashingservice::wash()?

in these examples specific service name seems appropriate. after all, in real life, "car washing service" makes sense. may end lot of services...

*note: not question opinions! precise, answerable question domain driven design methodology. i'm weary of close votes when asking "should i", there is ddd way of doing things.*

i think it's if domain service has 1 method. don't think rule must not have more 1 method on domain service or something. if interface abstracts 1 thing or 1 behaviour, it's easy maitain granularity of domain service totally depends on bounded context. focus on low coupling , neglect high cohesive.