Orientação a Objetos em si não fala de sistemas distribuídos, ou persistência, ou segurança, ou qualquer coisa parecida. Dado isso você tem que pensar que não pode expôr objetos, tem que expôr componentes.

EJBs, em chamadas remotas, são componentes e não objetos.

De qualquer modo se um dia desses você fizer um post mais detalhado sobre esse assunto acho que seria muito legal.

Ate mais.

Antes de mais nada este tópico não é sobre Domain-Driven Design, mas ainda que fosse você precisa identificar o que é domínio e o que é processo atual. O objetivo de DDD ou OO não é modelar o mundo exatamente como ele é e sim modelar o domínio, o que é algo bem diferente.

No domínio todas as inormações que dizem se o pedido foi cancelado ou não estão dentro dele mesmo. O pedido não pensa e nem a pessoa neste caso. O pedido contêm a informação necessária, a pessoa apenas olha o pedido e te dá a informação dele.

A maioria dos papéis “burros” como olhar para uma folha de papel e ver se tem um carimbo REJEITADO não é modelada diretamente, apenas as tomadas de decisão. O papel da “pessoa que te diz isso” não é exercido por uma classe que extrai essa informação e sim por um intermediário como uma interface gráfica que exibe o status do pedido.

Ainda assim, mesmo que você resolva modelar o papel das “pessoas” no processo como classes (fugindo de DDD) isso não te impede de usar objetos que recebem mensagens.

Na vida real você não pergunta para o pedido se ele é válido ou não. Na vida real você pergunta para uma pessoa com o conhecimento do dominio se tal pedido é válido ou não. Sendo aquela afirmação verdadeira, por que no sistema teria que ser diferente? Não é o objetivo do DDD representar o dominio na vida real no desenho do software?

@Diego
Se eu entendi alguma coisa, um pedido define seu estado pelos seus próprios atributos(incluindo agregações), se estes atributos são preenchidos do banco de dados ou de web services é responsabilidade da camada que lhe retorna este objeto “preenchido”(dao?).

No modelo/negócio, o isFinalizado() verifica seus atributos e checa se esta tudo OK. Esta é a lógica do negócio que este modelo(Pedido) representa, veja que este não cuida de buscar os dados, apenas de trabalha-los.

Bom… é assim que eu entendi.