DDD e uma tecnica poderosa para se construir software focado no negocio da organizacao e apoiado na linguagem corrente dos que irao utilizar o sistema. Dessa forma, o aplicativo e construido de "dentro para fora", permitindo que regras de negocio sejam implementadas (e testadas) bem antes da construcao das outras camadas e partes importantes do sistema como telas, controles e bancos de dados.Em algum momento, teremos que implementar funcionalidades para outras camadas e alguns servicos essenciais como controle de transacoes, object pool, injecao de dependencia, persistencia dos objetos de dominio, etc. Nesse post vou apresentar uma ideia geral de como poderiamos realizar essas tarefas de modo bem simples usando EJB 3.0.Antes de tudo uma observacao: se voce (como eu) odeia as complexidades e complicacoes do EJB 2.0 e torceu o nariz no instante que leu o titulo desse post, saiba que a versao 3.0 e completamente diferente da anterior. Os session beans e entidades JPA sao agora objetos leves e que permitem (entre outras coisas) que sejam testados fora do container que os gerencia. Se voce gosta da ideia de trabalhar segundo as premissas de Eric Evans e curte criar POJOs para resolver seus problemas entao EJB 3.0 e a ferramenta perfeita para suas necessidades.Primeiramente, vamos criar uma interface generica para nossos repositorios:@Localpublic interface Repositorio<T> { List<T> buscarTodos(); T buscarPorID(int id); void add(T object); void remove(T object); void update(T object);} Nao fosse pela anotacao @Local poderiamos dizer que essa seria uma interface comum escrita em Java. Aquela anotacao diz que essa interface permitira acesso a uma referencia de um session bean que reside na mesma maquina que o container web. Caso precisassemos de acesso remoto, bastaria anotar a interface com @Remote para termos acesso a um enterprise bean residente em outro servidor.Vamos agora implementar a interface Repositorio em uma classe RepositorioDeClientes: @Statelesspublic class RepositorioDeClientes implements Repositorio<Cliente> { @PersistenceContext() private EntityManager entityManager; public List<Cliente> buscarTodos() { Query query = entityManager.createQuery("select c from Cliente c"); return query.getResultList(); } public void remove(Cliente object) { entityManager.remove(entityManager.merge(object)); } public Cliente buscarPorID(int id) { Cliente cliente = entityManager.find(Cliente.class, id); return cliente; } public void add(Cliente object) { entityManager.persist(object); } public void update(Cliente object) { entityManager.merge(object); } }RepositorioDeClientes e uma classe POJO normal, transformada em um poderoso session bean sem estado atraves da anotacao @Stateless. O container gerencia um pool de objetos RepositorioDeClientes para servir aos usuarios de seus servicos - usuarios dessa e de outras aplicacoes. Alem disso, usamos o recurso de dependency injection com a anotacao @PersistenceContext, que serve para injetar um objeto EntityManager, elemento JPA responsavel em gerenciar o provider OR/M usado na camada de infra-estrutura.JPA, atraves da interface EntityManager, gerencia as entidades marcadas com a anotacao @Entity fornecendo servicos de persistencia para os objetos. Funciona como um "guarda-chuva" para os diversos providers de mapeamento objeto relacional existentes no mercado como TopLink e Hibernate (para o exemplo o provider utilizado foi o Hibernate).Anotando a entidade cliente:@Entity@Table(name="CLIENTES")public class Cliente implements Serializable { @Id @GeneratedValue(strategy=GenerationType.AUTO) @Column(name="CLIENTE_ID", nullable=false) protected int clienteID; @Column(name="NOME", nullable=false) protected String nome = ""; @Column(name="LOGIN", nullable=false) protected String login = ""; @Column(name="EMAIL", nullable=true) protected String