Conceito: Entidades com requisitos de negócio

Programação Arquitetura
#1

Não tem nenhum contra essa abordagem. Se acha que serve pode experimentar. Para referencia, o nome do padrão é command.

#2

Tirando o trocadilho de lado , não acha que sua entidade Servico deveria ser um Service e não um Entity?
Na verdade não é Command, tá mais parecido com Strategy. Não vejo nenhum problema nesta abordagem.

#3

Conceitualmente falando, e furando um pouco a DDD, quais as "regras" que são quebradas trazendo algumas regras de negócio para as entidades (persistentes).

Exemplo:
Objeto Serviço, possui alguns atributos (nome_servico, nome_executavel, data_inicio, data_fim, …)
Uma especialização de Serviço, por exemplo Servidor WEB, possui os mesmos dados persistentes de um Serviço qualquer, porem, muda a implementação de seu método executar() (exemplo);

Imaginem isso:

interface Executavel {
  void executar();
}

@Entity
class Servico {

  // @ <- omitidos; mas entendam que essa é uma entidade persistente
  String nome, executavel;
  Date data_inicio, data_fim;

  Executavel exec;

  Servico(Executavel exec) {
    this.exec = exec;
  }

  void iniciar() {
    exec.executar()
  }

}

class ServidorWeb implements Executavel {
  void executar() {
    System.out.println("Interpretando HTML...");
  }
}

class MainTeste {
  public static void main(String...args) {
    Servico s = new Servico(new ServidorWeb());
    s.iniciar();
  }
}

Obs. Em partes, o tratamento é parecido com Thread/Runnable, porém, sem a integração da persistência.

Lembrando que os atributos "exclusivos" de ServidorWeb não são persistidos na mesma camada de Serviço.

Quais os prós e contras desse tipo de abordagem?

#4