Depende… essa “ação” que você diz pode ser de um Entity ou de um Value Object, também. Não obrigatoriamente, essa operação deve ser colocada em um service, seja este de domain, de application, de insfrastructure, ou da camada que for. Um domain service, por ex., deve ser usado para representar (e explicitar) uma operação que não tem uma relação natural com um Entity ou um Value Object.
Bom, não entendi bem o que você quer dizer com “Sistema como um todo”, mas, de qualquer forma, se o seu domínio usa um modelo de objetos (Domain Model - PEAA) poderiamos ter:
joao.compra(carro); // num relacionamento bidirecional, o carro deve saber que o joao é o próprio dono.
joao.casaCom(maria); // a mesma coisa acontece aqui, onde a maria sabe que se casou com joao.
joao.ehAvaliadoPor(maria, 10); // joao conhece suas avaliacoes, e, agora, recebeu mais uma de maria.
Naturalmente, se necessário, poderia também ter um domain service quando a lógica de avaliação é importante e complexa, como:
public ServicoAvaliacaoImpl implements ServicoAvaliacao{
private RepositorioUsuario repositorioUsuario = ...;
public void usuarioEhAvaliadoPorOutroUsuario(Usuario usuario, Usuario outroUsuario, int nota){
usuario.ehAvaliadoPor(outroUsuario, nota);
//... mais lógica envolvida quando um usuario é avaliado por outro usuário
}
}
E uma possível implementação para Usuario poderia ser…
class Usuario{
private List<Avaliacao> avaliacoes = ...;
public void ehAvaliadoPor(Usuario outroUsuario, int nota){
adicionaNovaAvaliacaoDe(outroUsuario, nota);
}
private void adicionaNovaAvaliacaoDe(Usuario outroUsuario, int nota){
this.avaliacoes.add(new Avaliacao(nota, outroUsuario));
}
...
}
Neste caso, podemos assumir que Usuario e Avaliacao fazem parte do mesmo aggregate. O root dele, naturalmente, é o Usuario.
Um Value Object, no domínio, pode conter lógica de negócio também.
Bom, não é simplesmente porque não ‘altera’ o próprio objeto que deve ficar no Service. Acho que é uma regra muito simplória.