É possível conciliar DDD com EJB3?

Programação Arquitetura
#1

Não é mais uma discussão sem fim sobre repositórios. :slight_smile: Acho. :smiley:

É o seguinte, atualmente estou lendo dois livros, um é o EJB 3 In Action e o outro é o Applying DDD and Patterns. E aí surgiu uma dúvida: é possível ter DDD com EJB3? O livro do EJB diz que sim, mas não explica muito. O livro do DDD é com exemplos em C#, portanto, mesmo eu não tendo lido tudo, sei que não vai falar sobre EJBs.

Pra explicar melhor, um exemplo. Imagine um site de venda de produtos muambados, tipo Mercado Livre. Lá, a oferta de um novo produto pelos vendedores pode ser feita com o seguinte código:

Produto p = new Produto()
                .descricao("iPhone 16GB")
                .valor(new BigDecimal("1700.00"))
                .quantidade(100);

vendedor.oferta(p);

Tudo bastante OO.
Porém, como vendedor é um entity bean vindo remotamente, eu devo cercar o código acima pra ficar mais ou menos assim:

// aqui, mercadoService é uma variável cujo tipo é uma interface de um EJB 3
// o método procuraVendedorPeloId, no outro nó, vai buscar um vendedor na base de dados
Vendedor vendedor = mercadoService.procuraVendedorPeloId(15383242);

Produto p = new Produto()
                .descricao("iPhone 16GB")
                .valor(new BigDecimal("1700.00"))
                .quantidade(100);

// as alterações de estado do vendedor (e, possivelmente, produto) são de conhecimento
// apenas local, no lado remoto não aconteceu nada
vendedor.oferta(p);

// mando as alterações para o lado remoto, com o risco de uma transação não-ACID
mercadoService.salva(vendedor);

Achei super estranho a primeira e a última linha do código acima, porque parece meio procedural. Aí a dúvida: isso deixou de ser DDD? Se sim, existem formas de se contornar isso (além da opção de se desistir de EJB3)?

#2

Pq vc não usa a abstração que o repositório oferece para procurar pelo Vendedor ?
Ao contrário do que se vê, um repositório pode ser bem mais do que uma simples interface de um DAO, ele é um repositório de dados do negócio. Se os dados estão remotos, locais, em banco, em memória, não interessa… um repositório provê ele para você. A interface de seu EJB3 pode estar dentro do seu repositório ou seu repositório pode ser a própria façade (caso toda a manipulação em seus métodos seja remota).

#3