Los daos son independientes de JPA, o Hibernate, o cualquier framework que uses para tu capa de acceso a datos....
Los BO, o DTO, a veces se usan sólo para encapsular datos, pero me he encontrado lugares que les llaman indistintamente como lo expones, o como lo puse, o como "modelos" o simplemente beans....y pues serían parte del modelo, si es que los usas para reflejar las tablas de tu base de datos....

OK, pues entonces ando por la calle de la amargura, te intentare explicar que tan perdido estoy y ya tu me explicas lo perdido que me falta alcanzar a ver que estoy XD.

Utilizo los DAOs solo para la gestión de lo que llamo entidades [entidades de JPA] los BOs los utilizo para implementar lógica del negocio como calculos, movimientos, validaciones etc, y los controladores solo para hacer algunas validaciones simples de fechas o valores negativos que lleguen desde la vista [jsp basicamente].

De tal forma que quedaría de alguna forma así:

-Vista
-Controladores
-BOs
-DAOs
-Entidades

Y a veces hasta meto una capa de "servicio" entre los BO y DAOs.

Los DAOs tienen las consultas simples de Alta, Baja, Cambio y consulta de entidades y a veces los servicios los pongo para hacer consultas formateadas por ejemplo obtener solo las entidades que son mujeres y así... espero haberme explicado..

seguramente estaré erróneo en varias pero así lo he venido haciendo.

Pues mira, yo como lo he venido trabajando:
Vista: JSP, HTML, o JS con validaciones sencillas, pero que tienes que reforzar con validaciones en la capa de servicio...
Controladores: Servlets, Controllers de Spring
BO: Beans con datos simples, con datos que necesitas encapsular para transportar datos entre capas, pero que NO reflejan entidades en la base de
datos.
Daos: Como lo mencionas, son las clases que contienen métodos de acceso a datos
Entidades: Beans que reflejan una tabla de la base de datos, generalmente se gestionan con un ORM (Hibernate, JPA, por ejemplo)
Y la capa de servicio que mencionas, si es válido, puesto que ahí manejas operaciones con datos, invocaciones a otros servicios, o bien a clases de utlierías, validaciones, etc....
Si en algo estoy incorrecto, también agradecería opiniones de los amos del universo para que den otros puntos de vista....

Los BO son parte del modelo y se ubican en el Biz Tier de una aplicación multitier

Un objeto de negocio en el software, es una construcción que tiene una correspondencia directa con "algo" del problema de negocio que quiere resolverse con un sistema de software.
Ese objeto encapsula la lógica de negocio relacionada con esa "cosa" en el espacio del problema y también encapsula los datos que son necesarios para esa lógica.
En una aplicación que utiliza BO's, el cliente (¿quien es el cliente de un BO?) interacciona con los BO's, quien se encarga de administrar su persistencia utilizando algunas de las estrategias de persistencia existentes. Una de esas estrategias es hacer uso de DAO's para independizar al BO de la fuente de datos que se utiliza para la persistencia.
Los BO's implementan una capa reutilizable de entidades de negocio que describen el dominio de negocio. Ellos son "componentes" de grano muy fino que en muchas ocasiones no son utilizados directamente por una fachada de negocio sino por "servicios de negocio" que implementan una funcionalidad de grano más grueso, haciendo uso precisamente de los BO's. La fachada de negocio hace uso entonces de esos servicios de negocio que son descritos por el patrón Application Service.

Como hay mucha gente que escribe sobre patrones y cosas afines, también hay diferentes términos para referirse al mismo concepto. Los BO's también son conocidos como DO's (Domain Objects). Martin Fowler, por ejemplo, los incluye dentro del Modelo de Dominio, que define como un modelo de objetos del dominio que incorpora tanto comportamiento como datos. Cuando Fowler se refiere a un modelo de dominio anémico se está refiriendo precisamente a un modelo formado por objetos de negocio que encapsulan datos simplemente.
Los BO's pueden hacer uso de otros BO's que a su vez están relacionados con sus DAO's respectivos. En la literatura de patrones se usan los términos ParentBO y DependentBO. El primero es usado por un "Application Service" o a veces usado directamente desde una fachada de negocio. El Parent BO usa entonces a sus BO dependientes.
No es "común" un diseño donde aparezca un "servicio" entre un BO y un DAO.

Varias observaciones:

Los BO o DTO NO PERTENECEN al patron MVC. Con el objeto de facilitar la comprension, imaginate las tres capas del MVC, una sobrepuesta sobre otra. Los BO o DTO, serian una "capa" adicional (acuerdate que estamos imaginando) que se encuentra al lado de las tres capas del MVC, pero tiene la misma altura. Es decir los BO o DTO, recorren toda la estructura del MVC.

El concepto "Modelo de Dominio" se refiere a la relacion entre las entidades del mundo real y los objetos que se van a crear en nuestra aplicacion, Ejemplo:
- Si vamos a hacer un software para un contador las entidades del modelo de dominio, seran, las facturas, la cuenta del banco, etc. Observacion: generalmente el contador no es parte del modelo de dominio.

Generalmente se usan los BO o DTO para representar estas entidades del modelo del dominio,

Generalmente hay una relacion muy estrecha entre DAO y (DTO o BO), de hecho, en un esquema completamente orientado a objetos, cada (DTO o BO) deberia tener una tabla relacionada (considerando una BD relacional), con su propio DAO.

El patron DAO tampoco esta descrito dentro del MVC, pero debido a sus responsabilidades se le considera dentro del Modelo.

Les recomiendo mucho estudiar los patrones GRASP. EL libro uml y patrones de Craig Larman tiene al menos dos capitulos dedicados a estos patrones.

Entendí lo de los BO que se parece mucho a lo que hago, pero al incluir tanto termino técnico no logran separar bien en mi cabeza si un BO es una entidad[como tal de JPA] o hasta un DTO porque cada que mencionan a los BO también pueden estar describiendo las entidades o DTO [neko].

entiendo que el BO implementa la lógica del negocio y no como una entidad de la base de datos si no como una entidad que provee lógica y manipulación de esas entidades [JPA en este uso de entidad]... ¬¬.
Me viene un problema por que entidad se puede referir a una entidad Java y una entidad JPA @Entity... :S llamare a los java objetos y a las de persistencia entidades...

Y con lo anterior me refiero que a veces lo describen como un objeto que tiene funciones de entidad, otras como un objeto que tiene implementada la lógica del negocio ¬¬ ... pero las entidades tienen implementada la logica del negocio [por eso en parte creo que los BO son parte del Modelo] y ahora también me están diciendo que sirven para transportar datos como un DTO / VO.

Así que, io creo que si entendí bien y que los BO llevan lógica de negocio, manipulación de entidades [a partir de DAOs en mi caso], no sirven para intercambio de datos [es decir no cargas info en un BO y lo envías como una entidad], y representan la solución, cada uno a una parte del problema que el cliente quiere solucionar.

Espero un Sí eso es, o un no es así.

Muchas gracias bastante útil que me han sido sus respuestas.

Creo que te confundimos.

Primero quiero aclarar que utilizare las letras BO para representar a los business object y a los DTO.

Entonces te voy a presentar un BO (olvidate de relacionarlo con un jpa porque son dos cosas diferentes):
 

Como puedes darte cuenta, solo contiene la informacion de la entidad del mundo real y generalmente se mantiene asi, solo en pocas ocasiones es necesario agregarle un algoritmo en sus metodos, y si existe este algoritmo no va a estar relacionado con la logica del negocio.

La logica esta distribuida entre el controlador y el modelo. Acuerdate que el controlador es un tipo administrador o gerente (verifica las condiciones y da ordenes), y el modelo es el que haces los calculos, obtiene la informacion de la base de datos, etc.

El JPA esta considerado dentro del modelo y su tarea es consultar la base de datos y con la informacion que obtuvo crear BOs.

Espero que me haya explicado.

Te muestro otro BO :)

Te recomiendo leer
Tambien te recomiendo volver a leer lo que escribi y vas a darte cuenta que hay mucha similitud.

Las empresas o instituciones crean tecnologia, y obviamente deben de ponerle nombre a los componentes y comportamientos o funciones de estas tecnologias creadas. Muchas veces estos componentes o funciones tienen un gran parecido con la tecnologia que ya existe. A la mejor es lo que te esta confundiendo. Son muy parecidos los Entity beans, los DTO y los BO.

MVC es un estilo o patrón para separar tres concerns importantes de cualquier aplicación de cómputo: El control de la aplicación, que determina qué es lo que debe hacerse como respuesta a un solicitud del cliente de esa aplicación, y que delega esa solicitud a la lógica de negocio que se encarga de realizar lo necesario para satisfacer ese caso de uso y actualizar el estado de la aplicación, o actualizar el estado del modelo y que sea interrogado por la vista que muestra el resultado del caso de uso.
Tanto la lógica de negocio como el estado de la aplicación constituyen el modelo.
Una vez que se ha completado la ejecución de ese caso de uso invocado por la solicitud del cliente, tiene el controlador que despachar la vista que visualiza el resultado obtenido haciendo uso del modelo que representa el estado corriente de la aplicación.
Es variada la implementación que puede hacerse para que el controlador asocie la vista con el modelo obtenido, y variada entonces serán las posibles dependencias que existan entre esas tres partes. En un buen diseño, lo que se persigue es tener la menor dependencia entre ellos.
Los objetos de negocio u objetos de dominio deben encapsular la lógica de negocio y los datos asociados a la entidad del dominio que están modelando y construyendo en el software. Son componentes de negocio de grano muy fino, que como comenté en mi post anterior son puestos a trabajar en un servicio de negocio.
Es incorrecto diseñar objetos de negocio como objetos anémicos, como los ejemplos que pone beto bateria, donde solamente encapsula datos en los objetos de negocio y deja entonces que las funcionalidades que se le pueden asignar a esos objetos se manipulen por un servicio de negocio. Al hacer eso, se requieren más interacciones entre los objetos de negocio y se hace más compleja la lógica de los servicios de negocio, con el aumento considerable de dependencias y la poca reusabilidad de esos objetos de negocio.
Los objetos de negocio representan entidades persistentes y por esa razón es que siempre están relacionados con algún otro objeto que se encargue de su persistencia. No conviene encapsular en el objeto de negocio sus necesidades de persistencia.
Si la persistencia se está resolviendo con objetos DAO, entonces cada objeto de negocio tendrá su DAO al lado. Si la persistencia se está haciendo con una implementación de un Domain Store, el dseño será diferente.
Los BO no son objetos DTO. Esos DTO son los que se transfieren entre los diferentes tiers de la aplicación y no los BO. Esos DTO existen con independencia de que tengan que ser programados o que sean representados por las propias entidades como es el caso de algunos diseños con JPA.

Quizá lo siguiente contribuya a lo que comentamos.

Así describe Core J2EE Patterns al patrón Business Object

Problema:
Se tiene un modelo conceptual del dominio con lógica de negocio e interrelaciones

Fuerzas que mueven a encontrar una solución:
Tenemos un modelo conceptual que contiene objetos compuestos interrelacionados y estructurados
Tenemos un modelo conceptual con lógica de negocio sofisticada y reglas de negocio y validación
Queremos separar el estado y comportamiento del negocio del resto de la aplicación, mejorando la cohesión y la reutilización
Queremos centralizar en una aplicación el estado y la lógica de negocio
Queremos incrementar la reutilización de la lógica de negocio y evitar la duplicación del código

Solución:
Utilice Objetos de Negocio para separar los datos y la lógica de negocio usando un modelo de objetos

Mencione que:

Las empresas o instituciones crean tecnologia, y obviamente deben de ponerle nombre a los componentes y comportamientos o funciones de estas tecnologias creadas. Muchas veces estos componentes o funciones tienen un gran parecido con la tecnologia que ya existe. A la mejor es lo que te esta confundiendo. Son muy parecidos los Entity beans, los DTO y los BO.

La diferencia entre DTO y BO es que los BO son DTO pero con comportamiento. Es decir si tengo un objeto llamado Factura, si es un BO podria tener un metodo llamado getTotal(), si es un DTO no lo tendria.

Hago referencia al podria al definir el BO, debido a que dependiendo de los requerimientos, arquitectura y la mitica batalla de la Alta cohesión y bajo acoplamiento se podria definir en el diseño que Factura no tuviera el metodo getTotal().

bferro menciono:

Es incorrecto diseñar objetos de negocio como objetos anémicos, como los ejemplos que pone beto bateria, donde solamente encapsula datos en los objetos de negocio y deja entonces que las funcionalidades que se le pueden asignar a esos objetos se manipulen por un servicio de negocio. Al hacer eso, se requieren más interacciones entre los objetos de negocio y se hace más compleja la lógica de los servicios de negocio, con el aumento considerable de dependencias y la poca reusabilidad de esos objetos de negocio.

Sin embargo, siempre he usado DTOs en la arquitectura de mis aplicaciones y he podido pelear mejor contra la alta cohesión y bajo acoplamiento, pero esa es mi experiencia, si tu(bferro) decides usar BOs al diseñar tus aplicaciones pues es respetable, tal ves en alguna ocasion lo haga, y contare como me va,

bferro, me parece que escribimos el ultimo comentario al mismo tiempo.

Copio aquí una nota de diseño sobre este asunto. La nota es del libro Core J2EE Patterns y viene a colación con lo que estamos comentando. La dejo en su idioma original:

Design Note: Business Object Wraps Transfer Object

Some developers have a tendency to wrap Transfer Objects with Business Objects because the state information required maintained is similar to the state information represented by the Transfer Object.
Another reason why developers tend to wrap the Transfer Object with a Business Object is because
they feel that Transfer Object are proliferating the system and by reusing them somehow, it is possible to limit the proliferation and to make the Transfer Objects more useful in other ways. This logic is flawed due to the following reasons:

What about the intent of the Transfer Object?
The intent of the Transfer Object is to carry data across the tier and not model the state of a Business Object. This intention is violated by this strategy as it lends additional meaning to the transfer object. If the Transfer Object reuse is more important than keeping them true to their intention, then you might want to use this strategy. A Transfer Object is intended to facilitate a use-case's specific data transfer needs and reflects that use-case's requirement very closely.

What happens if you add or remove a field in the Transfer Object?
Changing a Transfer Object may require a change to the Business Object if that change needs to be reflected to the Business Object's clients. For example, if you remove a field, then the Business Object might need to be modified to reflect to this change. Such changes can have wide repercussions in the business objects layer and beyond.

What happens if you add or remove a field in the Business Object?
If you add a new field to the Business Object, or remove one that existed, then the Transfer Object will have to make the corresponding change to keep up. Such a change can have a cascading effect and affect a change in all the clients that use the Business Object and the Transfer Object .

What if the Business Object needs to send a different Transfer Object to the client than the one it wraps?
The Business Object has to create a different Transfer Object as required by its clients, regardless of the one it wraps. This only contributes to more proliferation of Transfer Object than to limit it.

What happens if the Business Object needs derived fields that are then sent to the clients?
This implies that the Business Object has to create another Transfer Object to send the derived data anyway. Or you can change the existing Transfer Object to accommodate the additional fields to carry derived data. This has the same effect as described previously when you change a Transfer Object .

Bueno eso si lo he usado pero nunca extendiendo de Business Objetable [ni siquiera sabia que existía] y es a lo que estoy nombrando como entidad.

es decir BO=entity
y DO=BO=entity

y si esto es asi como se llamaría la capa que llevaría la lógica de negocio? o solo tendría que trasladar eso a la capa de controlador [todo esto, dando por echo que no se implementa la capa de servicio que ya habían mencionado]

En el post que se marcó como spam, incluí una nota de diseño del texto CoreJ2EE Patterns que se refiere precisamente a la mezcla de los BO con los TO. La dejé en inglés.
La escribo nuevamente aquí en español.
Nota de Diseño: Cuando los objetos de negocio "envuelven" (del inglés wrap) a los objetos de transferencia

Algunos diseñadores tienen la tendencia de "envolver" a los objetos de transferencia (TO) con los objetos de negocio debido a que la información de estado requerida es similar a la información del estado representada por los objetos de transferencia.
Otra de las razones por ese tipo de diseño es que esos diseñadores sienten que los objetos de transferencia están proliferando el sistema y reusándolos a ellos de alguna manera, es posible limitar ese crecimiento y lograr que los objetos de transferencia sean útiles para otras cosas.
Esa forma de diseñar es "defectuosa" por las siguientes razones:

¿Cuál es la intención de un TO?
La intención del TO es transportar los datos hacia otro tier y en ningún momento modelar el estado del Objeto de Negocio. Esa intención se viola con esta estrategia y añade otro significado al Objeto de Transferencia. Si la reutilización del Objeto de Transferencia es más importante que mantener su verdadera intención, entonces podría ser aceptable esta estrategia. Un Objeto de Transferencia está para facilitar la transferencia de datos de un caso de uso específico y refleja ese requerimiento del caso de uso de una manera fidedigna.

¿Qué pasa si añadimos o eliminamos un campo del Objeto de Transferencia?
El cambio en un Objeto de Transferencia puede requerir un cambio en el Objeto de Negocio si ese cambio debe reflejarse a los clientes del Objeto de Negocio. Por ejemplo, si eliminamos un campo, entonces el Objeto de Negocio tiene que ser cambiado para reflejar ese cambio. Esos cambios pueden tener repercusiones significativas en la capa de objetos de negocio y más allá de ella.

¿Qué pasa si añadimos o eliminamos un campo en el Objeto de Negocio?
En este caso, habrá que reflejar esos cambios en el Objeto de Transferencia. Un cambio así puede provocar un efecto de cascada y afectar un cambio en todos los clientes que usan el Objeto de Negocio y el Objeto de Transferencia.

¿Qué pasa si el Objeto de Negocio tiene que enviar un Objeto de Transferencia diferente del que "envuelve"?
El Objeto de Negocio tiene que crearlo con independencia del que ya "envuelve". Esto solamente contribuye a una proliferación de objetos de transferencia en lugar de limitar su cantidad.

¿Qué pasa si el Objeto de Negocio necesita campos derivados que son entonces enviados al cliente?
Esto implica que el Objeto de Negocio tiene que crear otro Objeto de Transferencia para enviar de alguna forma esos campos derivados. O también podemos cambiar el Objeto de Transferencia para acomodar a los campos derivados. Esto tiene el mismo efecto que el caso anterior.

Son consejos sanos de un buen diseño arquitectónico.

Bueno, entonces, lo que yo entendí es:
Que los VO o DTO o TO pueden ser, en escencia, lo mismo que un BO, a diferencia que éste último puede tener métodos con algún comportamiento específico? lo menciono, porque, como menciona @beto.bateria, por ejemplo, tengo un VO que tiene propiedades :
 
sería un BO si tuviera un método que fuera:
 
y que ése método sumara los valores de   y   ??
Otro comentario va para lo que comenta @bferro, que lo que entiendo es que no se recomienda el uso de envoltorios en las clases que representan objetos de transferecia de datos, porque si se llega a modificar, ya sea el envoltorio, o la clase envuelta, se están acoplando demasiado los objetos, al grado que una modificación en algún elemento, no sería algo sencillo....si es así o me perdí ??
Ahora, si es correcto lo que mencioné en el párrafo anterior, entonces, no refleja algún tipo de peligro para mi aplicación usar mis "entidades" como objetos de transferencia? para ser más claro, pongo un ejemplo:
Puedo tener éste DTO
 

brincando dentro de las capas de mi aplicación sin ningún problema? o debería de crear alguna clase con propiedades similares, además de alguna utilería para copiar los valores? digo esto, porque me surge la incógnita de que, por el montón de anotaciones que manejo, podría estar exponiendo la representación de una tabla de base de datos...o no??

@offtopic: Creo que estoy comenzando a desviar el tema.... :¬|
@offtopic 2 : Mr bferro, sigo esperando (y no creo ser el único) fechas para cursos de arquitectura de software y Scala :¬)

Bueno, pues esperaba algo más simple, más o menos a lo que me han dicho lo entiendo, expongo de manera diferente:
 
  
 

Así es como lo he venido manejando, por lo que alcance a entender de las fanfarroneces que dicen es que probablemente la entidad sea un BO.... y mi BO no exista si no que este funcionado con la Misma entidad o quizá se podría representar la capa de servicio, o quizá los servicios van enfocados a funcionalidades grandes del sistema y varias Entidades [o BO] les proveen de información u otras cosas. Y supongo que mi DTO esta bien....

Me da la impresion que no me he explicado bien, por esto:

El codigo de PersonaBO parece mas un wrapper o adapter que un BO. El BO es un DTO (exactamente) mas algunas funcionalidades, al desarrollar una aplicacion, o usas DTO o BO.

Cuesta trabajo entender todo este rollo de patrones, asi que no te martirizes si en estos momentos no le entiendes. A la mejor se necesita un ejemplo que este mas cerca de la realidad.

eso que pongo es como lo he venido usando... y se me hace que te centraste mucho en el método auxiliar "transforma", era más por los cálculos que se hacen.

pero entiendo lo que me comentan hasta cierto punto en el que se ponen demasiado técnicos y como no tengo tanta teoría pues me pierdo, pero prácticamente entiendo que mis Entidades @entities son BO y se confunden a veces con los DTO = VO [parecidos o iguales para el caso]; que a los BO a veces los nombran como DOs y que la capa de servicio engloba funcionalidades, solo que las validaciones y calculos grandes no se donde los dejan... regularmente las entidades solo las tomo como portadoras de información a la capa de persistencia solamente y para pasar info de la capa de Controlador a la vista a veces uso las mismas entidades=BO y otras veces se utilizo un DTO [como en el ejemplo] el cual no persisto si no que utilizo para motivos muy específicos.

De eso si entendí algo mal sería ayuda que se explicara.

BO=@Entity [parecido a] DTO

Debido a esto las entidades a parte de persistirse en la Base d Datos SUPONGO que también implementan funcionalidades y métodos a parte de los setters y getters comunes según han venido comentando por eso comente que probablemente lo que conozco como BO [no los verdaderos BO] están incluidos en las entidades [los verdaderos BO -.-], bueno espero haberme explicado y si entendí mal se agradece que me sapeen ^^...

Bueno beto Bateria esta equivocado, como dicen en mi tierra esta orinando fuera de la vacinica, bferro esta en lo correcto ese si es el maestro. sobre estos conceptos.

Pregunta para bferro el maestro, y la parte de la transaccion como la manejaria en una arquitectura orientada a dominio , me explico me refiero a la otomicida de la transaccion el begin trans el conmit trans y el rollback cuando hay que interactuar como mas de un objeto BO cada uno persiste los datos en su tabla de base de datos llamando a su DAO como explicas tu arriba, ¿Donde harias la conexion y como manejaria la transaccion? y si cada DAO abre y cierra la conexion al ejecutar un operacion contra la Base de datos ??

Para eso necesitas un TransactionManager, que puede ser algo tan complejo como JTA o algo más sencillo, pero la idea es que te olvides del manejo de conexiones y le dejes el control de eso al TransactionManager, que se encargará de abrir una transacción, para que las operaciones que mencionas se hagan dentro de la misma, y también causará que NO se cierren las conexiones como pasaría normalmente, y que todo se haga dentro de la misma conexión, y al final si todo sale bien hará el commit, o si se arroja alguna excepción se hará un rollback automáticamente.

Pero para que todo eso funcione, necesitas que tus DAOs no abran conexiones físicas directamente a la base de datos, sino que utilicen un DataSource que sea administrado por el TransactionManager, porque así cuando hagan   de una conexión, realmente el TransactionManager va a ignorar esa llamada si hay una transacción en progreso, y cuando los DAOs pidan una conexión nueva, realmente les dará la misma en donde se está realizando la transacción.

Algunos han dicho que el patrón de diseño DAO podría estar muerto:

• Has JPA Killed the DAO?
• JPA/EJB3 killed the DAO : Adam Bien's Weblog
• why DAO won’t die | brain driven development