En esta presentación, el autor (que es un miembro de la comunidad de Java Champions) explica una arquitectura para aplicaciones basada en los siguientes principios:

• Domain Driven Design (Diseño guiado por el dominio): se refiere a que los objetos que modelan el negocio (patrón Business Object) representan el estado del negocio e incluye cierto comportamiento (auto-validaciones, manejo de relaciones con otros objetos de dominio dependientes, CRUD). No sé si tiene algo que ver con los libros de igual título (“Domain-Driven Design” y “Applying Domain-Driven Design and Patterns“).
• Implementación de los objetos de dominio como entidades JPA.
• Otra lógica más allá de la que un objeto de dominio sea capaz de resolver por si mismo se debe implementar como una fachada (POJOs o stateless/stateful session beans). Estamos hablando del acceso al EntityManager de JPA, de la transaccionalidad, seguridad, trazas de auditoría…
• No se usan DTOs (patrón Transfer Object) sino que los objetos de dominio viajan desde la capa de negocio hasta la capa de presentación sin el sobrecoste de las transformaciones o las copias de valores.

La diapositiva 18 es especialmente clarificadora. Sin embargo, le he preguntado directamente a Adam Bien cómo encaja esta propuesta en una arquitectura orientada a servicios (SOA). Su respuesta ha sido que los servicios deben implementar lógica no relacionada con los objetos de dominio, mientras que las fachadas (o gateways, implementadas como SFSB) se encargan de lógica independiente de la instancia (como el CRUD) y exponen directamente entidades JPA (los objetos de dominio), que se almacenan localmente.



Me queda pendiente preguntarle cómo resolveríamos los problemas de concurrencia que provocaría un webservice que modificara registros en la base de datos que, a su vez, correspondieran a objetos de dominio presentes en la sesión de una de esas SFSB.